It is widely known that in Agile your team gathers every two weeks (typically) to set goals for the next iteration. It is less known, however, how to estimate tasks from the backlog in story points and how to use velocity to plan the appropriate amount of work for following iterations. Here is a step-by-step guide.
Why bother with story points?
Wouldn’t it be easier to estimate tasks in hours? Story points let you overcome the ever true problem of underestimation. It’s easier to say that “Fixing a coffee machine will take me 1 story point”, than to confess that “fixing the exact same machine would take me 16 hours”. Let’s face it: people are reluctant to openly admit, how impotent they are.
But there is another major benefit of using story points instead of hours: you can deliver potentially most profitable things first. This is called WSJF (Weighted Shortest Job First).
So how to plan iterations using story points and velocity? Let’s go into more detail.
See also: Story points in Jira explained
Step-by-step 20-minute guide
(1) Set a reference story (a typical reference task)
Example: Say, you are a coffee machine serviceman and we all know that sooner or later every coffee machine will stop dispense coffee for some reason. The more you master your job the more you believe that there are only a couple of typical reasons why coffee stops flowing. But having arrived at a client’s office to fix their machine you don’t know yet – possibly calc have accumulated in coffee block or maybe you would be replacing the water pump, and finally there is a marginal risk of non-standard failure.
And we didn’t mention that, but washing machines and refrigerators are in your portfolio too, so you are not that much of an expert. Instead, you can roughly say, that an average coffee machine breakdown equals to 1 story point.
And so work story points in any business. Sure, you are an expert in your field compared to an average Joe Doe, but you are not an infallible expert.
Things to consider:
- A good reference story should last for a relatively long period of time, so choose a typical – regular- average task a given team deals with. For our serviceman fixing his white van wouldn’t make a good reference story since repairing vehicles is not his core business.
- Record your reference story in some wiki (your company intranet). Our serviceman could note it down on paper.
- Consider updating your reference task in those rare situations, when the responsibilities of your team change. With our serviceman, it could be that he stops traveling to clients and instead he now services appliances on the site only. Therefore he should obviously update his reference task to reflect his new, more predictable job environment.
- Don’t worry about inexperienced team members at this stage. Think of who the majority of your team members are, and typically they are pretty knowledgeable and experienced. So set your reference task with those experienced in mind.
(2) Estimate tasks in your backlog
Now that you’ve set your reference story, browse through tasks in your backlog one by one and estimate them compared to your reference task.
Example. Our serviceman could say: replacing bearings of a washing machine drum involves lots of disassemblies, so compared to my reference task (coffee machine) the bearings in a washing machine shall be 2 story points.
Things to consider:
- use Fibonacci sequence, i.e. 1 story point, 2 sp, 3 sp, 5 sp, 8 sp, 13 sp, 20 sp – this will reflect the increasing uncertainty with more complex tasks
- if you think that an issue is over 20-story-point complex, then break it into sub-tasks of lesser complexity
- save the number in “Story points” field of your project management software (we use Jira + BigPicture)
- some issues could have null story point values, e.g.:
- bugs – in case you are in the software development business, like us
- ad-hoc conversations or meetings
- if you use Epics, decompose them into stories and then estimate a story, not an epic
(3) Calculate Capacity
Say, the cadence of your iteration is 2 weeks and your business is open 5 days a week. The capacity of a team member would be 10 days, but since one of your party of four took a one-day leave, that individual’s capacity would be 9 days. Now add capacities of the four team members: 10 + 10 + 10 + 9 = 39.
(4) Calculate Velocity
Two weeks (a single iteration) have passed, so you can calculate velocity. The circumstances were not the best, so even though your team had planned tasks with a total complexity of 20 story points for the past iteration, they have only managed to “burn” 10.
The velocity of that team is: 10/39 = 0.2564 story points.
Things to consider:
- remember those issues with 0 sp, namely meetings and bug fixing? You could have dedicated a fraction of each iteration to bug fixing and meetings. Say, 3 days of each iteration. Sure, these “0 sp days” will drag velocity down. But that’s o.k. You simply trade velocity for the predictability. In spite of putting aside three business days for 0 sp issues, your velocity still looks as follows:
10/39 = 0.2564 story points.
In other words: those three days in each iteration that had been dedicated to 0 sp issues might have caused the below-expectations velocity of 0.2564.
- velocity is not comparable across teams. Team A might have a velocity of 0.25 and team B – 0.5 and that’s o.k.
- the velocity of a team depends on various factors, e.g. how many people are there in that team, their skills
- but there are industries, such as software development, where velocity especially depends on one single factor – the amount of labor with 0 sp estimation, namely the aforementioned bug fixing and ad-hoc meetings.
(5) Plan iterations (finally)
Say, the capacity of your team in the upcoming iteration equals to (10 business days – one-day national holiday) * 4 team members = 36.
Given the previously calculated velocity of 0.2564 and those three business days that you’ve allocated to 0 sp tasks, plan tasks worth a maximum of 36 x 0.2564 = 9.23 story points for this next iteration. High-priority tasks go first.
What if there are no serious bugs on the backlog? Should your team still spend 3 days fixing bugs? Yes – says Pawel Guz, responsible for driving operational excellence in SoftwarePlant – if no high-priority bugs are found on the backlog then the team should spend the three days fixing lower-priority bugs. What’s more, the team could plan, say, further 20% of its capacity for meetings and other zero-story-point issues. Contrary to the aforementioned bug fixing 3-day cushion, the “meetings and others” buffer doesn’t have to be used up but it must not be exceeded. If the team saves time on meetings, it can allocate it for regular story point tasks or bug fixing.
Even with that precise planning more often than not it will turn out the team cannot deliver even those 9.23 story points. What now? Have you set “Goals for the iteration” or “Goals for Program Increment”. They will help you decide which tasks can be postponed until the next iteration and which cannot. Two tools in BigPicture let you set goals for iterations and Program Increments Board and Roadmap.
Capacity for Growth & Growth Velocity
Instead of ‘regular’ capacity and velocity, you could use these:
- Capacity for Growth = Capacity – time allocated for 0 sp issues
Example: Capacity for Growth of your team in the upcoming iteration equals to
(10 – 1 – 3) x 4 = 24
(10 business days – one-day national holiday – 3 business days allocated to 0 sp bug fixing and meetings) * 4 team members = 24.
- Growth Velocity = story points delivered (in past iterations) / Capacity for Growth
Example: 10 / 24 = 0.41(6)
10 comes from “(4) Calculate Velocity” section.
Pretty obviously, if you stick to the “for growth” variants, planning of the subsequent iterations would look as follows:
Capacity for Growth of a future iteration, say 7 days * 4 team members * 0.41(6) = 11.67 story points
After a few weeks or months using story points and velocity for iteration planning gets simple and intuitive. You certainly need some project management software – look around for the ‘Story Points’ field in your ‘edit task’ view. The whole thing boils down to deceiving the enemy, who are in fact your own team members, that try to prove to the management that problems can be solved painlessly in the more and more complex world.
Tomasz Kucharski, CEO