Developers hate giving estimates. We all know that they’re pretty much pie in the sky anyway; after all, how can you know exactly how much time it will take to develop something when you haven’t done it yet? The only time you can give an accurate estimate is after you’ve done whatever it is you’re planning, but that kind of defeats the purpose, doesn’t it?
Software development is complex and inherently unpredictable. Requirements are unknown and subject to continual change. Technology is constantly moving forward. People are at the heart of all we do and are also famously unpredictable. The rub is, however, that Product Owners and stakeholders need those estimates in order to make the most of their budgets and assess the business value of a project and when results will be available.
Yet there are just too many unknowns for the Developer to be truly confident that an estimate is correct. The problem then is that the ‘made up’ estimate you’re forced to give gets written down somewhere and suddenly becomes the yardstick by which everything is measured, yourself included. Estimates become commitments, even though that wasn’t the original intention and purpose.
If only there was a better way to make realistic estimates… oh wait, there is! Try using Relative Estimation and Story Points.
Story points replace traditional estimates in that you no longer have to try to guess how many hours a job will take. Instead you give each job a non-time based point according to an agreed scale, illustrating how easy/quick or how complex the undertaking is. Each item is then estimated relative to each other.
There is no one points system to use; each team can choose its own – the only thing that is important is that every single team member understands and agrees with the system and scale used.
Different teams choose different points systems: you could use x-small, small, medium, large and x-large, as if you were talking about T-shirts. Other teams have been known to use coffee cups for their inspiration – tall, short, grande etc… The more ambitious teams even use the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34 etc…). Or you could just use plain old numeric sizing, such as 1-10.
So instead of estimating that a job will take 20 hours, for instance, you might – according to your scale – give it 2 points. As the estimates are relative, a 2 point item will be twice the size (and should take twice as long to deliver) as a 1 point item.
Although we are abstracting away from time based estimates, the effort involved is still at the core of the Story Point size selected. It is after all how long something will take that we are seeking to forecast. This is conceptually a little difficult but starts to make sense once you do this. Trust me!
Story Points and Sprints
How does this fit into a Sprint? Well, first the team will give all items in the Product Backlog a Story point value, relative to one another. At the start of each Sprint, the team agrees to deliver specific Product Backlog Items (PBI’s) based on its capacity. The Sprint is then started and PBI’s are (often) then broken down further into tasks.
At the end of the Sprint, you add up the total number of Story Points completed and this becomes your velocity, which can be used to guide your capacity of how much work can be completed in a Sprint at your next Sprint Planning. This helps the team hone its planning even further. The more Sprints we have completed the greater confidence we will have in how much a team can complete in a Sprint.
And it’s genuinely that simple! Story points take the unknown out of giving estimates; once you select your scale, it’s quick and easy to accurately assess how much work you have on your hands and to plan going forward. The human brain is generally more comfortable estimating in this more abstract way and having to think less in terms of time to complete and more in terms of how large is this piece of work relative to other similar work we have completed in the past.
A couple of things to bear in mind:
- The Product Owner needs your estimates in order to effectively prioritise the Product Backlog.
- In order to avoid unconscious pressure when the team gives estimates even amongst itself, all Developers may choose to give their estimates simultaneously. Have a look at the “Planning Poker” technique for a useful way of doing this.
- Don’t be surprised if different Developers offer different estimates. Even when everyone understands the scale, there may still be some variation on how different people estimate something. In order to get an estimate that accurately reflects the entire team’s opinion of a story’s complexity, you may need to do a few rounds of estimation. Significant value will come from the discussion and the deeper understanding that will be gained from the discussion. The value in planning is as much about gaining this understanding, as it is to estimate the size of the work to enable future planning.
Don’t be afraid. Try something new and then inspect and adapt to tune it to make it work for you. That is what Scrum is all about.
The Kanban Master is Simon Kneafsey. Simon is an Accredited Kanban Trainer with the Lean Kanban University, the home of Kanban.
Simon offers Accredited Kanban training courses globally and works with clients to introduce Kanban to their organisations.
My Favourite Kanban Books2nd September 2016
Agile In A Day – Further Reading2nd September 2016
Agile in the mainstream2nd September 2016
Share this Post