Introduction

Over the time, I practised Scrum principles many times. As a team member, as an architect and also as a Scrum Master. I suggested Scrum principles to one of my clients and I had to wrote a couple of papers to lay down the principles and their benefice to management.

As the team development in place hasn't practised Scrum, I wrote a how-to article to members which I modified a little to share it with you. Still, this article is not intended to beginners because I removed many definitions, roles responsibilities, etc.

Background

When you try to get things well planned ahead, you may find yourself in situation that can be more complicated than your initial plan predicts.

For instance, if your organization has the likely traditional phases as design, code, test and deploy. So, as PM you plan 4 weeks design, 10 weeks code, 4 weeks testing, and then go to production and release the core team. On paper, everything looks just fine and all dates well aligned in MS Project sheet columns.

But, in the first phase, let’s say, you blow the estimation by 25%. What should do you do to keep the project on truck? Ask the development team to code fast to be able to respect the timeline and cut its planned time by 25%? Is it that fair or even a good decision?

Of course the development members (the team members) will point out that cutting their time by 25% will have consequences on quality. So, forget about the fully covered solution with Unit Tests. Is it what you really want? of course not.

So, you start thinking about solutions and maybe go to steering committee and ask management an extension or increase of 25% of time for all phases based on the fact that if design took 25% more time, it will be the same for coding and testing phases.

But this also will not work. Because the really problem you are facing here is the fact that you don't have all the facts and data that you based your estimation upon. It is the cone of uncertainty. You cannot possibly plan ahead everything and pretend that its a bad idea to change or adjust things. You should just accept the fact that that as the time progress, more details and data comes to light and the project estimation will be better and more accurate. This state the agile estimation. So face the problem and embrace Cone Of Uncertainty. Agile has to reestimate the project after each sprint. Those changes that come up with this needed exercise are re-equilibration and not a deviation or a bad thing to do in project development.

Old fashion folks will not get this very easily.

How to Estimate

We pick up the User Stories based on the client or Product Owner priorities and we give them the User Points during the estimation sessions of each sprint. Those sessions are called the poker planning. I used many unit of measurement (clothes measurements as XS S M L XL XXL, stones (in reference to Abacus) and it was a disaster! And I finally used and still using the Fibonacci suit number which is more simple and convenient.

But the most important things to do is to set those units or points based on comparison for something else. I usually use the getUserById function linked to the context of the project and it required some imagination and good words to get all team members on board in situations where this function didn't make any sense. So, a friend of mine suggested the login screen functionality as a baseline. I adopted it because everyone developed or used the login screen and started discussions based on that. Be aware that your point numbers will be based on your baseline functionality.

So the same estimation may have completely different number if it’s based on another functionality than the login screen. But you can adopt anything that may work for you and your team.

In the other hand, it is fine to be inaccurate. Take the number that come up in your negotiation. People are used to negotiation but some have more strong personality than others and that is why planning poker mitigate this aspect even if it cannot remove it completely.

Since people have the opportunity to vote upfront and discuss after that, they usually do it according to their experiences and competencies. And that's OK.

I am not saying that the planning poker is perfect. It just help to calm down larger personalities as negotiation tend to consensus but not trying to meet in the middle. All members of the team should participate because the points include analyse, code and tests.

Velocity

After the first sprint, you will get your velocity number, which is the points of your completed User Stories. The velocity will tell you how much work you should to commit to in next sprint. Don't worry if your first velocity is not accurate. If you keep estimating consistently the velocity will correct itself over sprints. Because after each sprint more details and light come up for the user stories, and your estimation will be better and the inconsistencies keeps going down.

Re-estimate

The team velocity, as I said before, keeps changing and getting better over time. After each sprint you have to re-estimate the entire project. So, should you go through the entire process again? Is it a waste of time? No. For the simple reason that the backlog changes over sprint: the product owner add more user stories (the forgotten ones) and push as highly priority the feature that was at the beginning a nice to have. There are also some completed user stories that need to be removed and some introduced bugs to be added. You end up doing the same process, not the same work.

Metrics

Of course, measure things is always a better and far more accurate than estimation. But what to measure exactly? Well, in this case the measures are just a way to compile the information that is at our hand sprint after sprint:

Number (or size) of the product backlog at the start and after each sprint: this will give you the number of items committed to, completed, missed, added and the velocity.

Change of the backlog: removed items because the product owner don't need them anymore, the bugs added during development.

% of team capacity to allocate to bugs/refactoring/amelioration/fine tuning after sprint 1.

There is many ways you can track and measure those things depending on what you want to do with it. I usually use an excel spreadsheet and plug into the data some charts to show how velocity is going and how close the team is to completion.

I usually show those charts to management to make them know how much sprints left to go to production and let them weigh time and budgets vs the % of increase in productivity and efficiency after production.