Cone of uncertainty
Above is a cone of uncertainty, this image demonstrates how larger stories come with greater risk when not broken down further.
Small stories between 1-3 pt’s shouldn’t have a grey area because for the team to know that a story is so small they should have a good grasp on what is required to deliver that story. I have placed the 5pt story on the line border of having grey matter, as though 5pt stories are of a size where the team should know whats required to complete the story, I have found in practice that this is not always the case and often 5pt stories end up being more like a 6pt’ish story
.
As the story sizes increase, so does the grey area, and the grey area is not directly relational to the ideal inner cone. Get your scrum master to keep track of estimations, the actual time taken to deliver and from this you will be able to calculate your teams multiplier for the ‘grey area’. You can then use this in your sprint planning sessions as a safety buffer.
How do you minimise the ‘grey area’? Due to the nature of large stories it is not possible to remove the grey area completely, but you can utilise methods to reduce the ‘grey’. Having well defined stories and story acceptance criteria all help reduce uncertainty around a story. Though I’d rather spend time out of a meeting, if you have a 10 pt story and your grey area multiplier suggests a 3pt buffer, but a meeting would only take 30 minutes to help add clarity to your story, do the meeting as this may reduce the 3pt buffer. Do all that you can to reduce the grey area, but accept that you will never be in a position to completely remove this grey matter.
Improving Sprint capacity planning – The safety buffer / net
If your team consistently struggles to meet their sprint commitments because they are over optimistic with their story estimations, try to create a safety buffer or safety net.
Often teams try to create a safety buffer by only filling their sprint backlog to 60-80% of their capacity, though this approach is reasonable it is not very flexible or accurate.
Instead if we measure the uncertainty around estimated story points and use this metric to determine how much of a safety buffer we need to put into place, this gives us tighter accuracy and improved burn rates.
To demonstrate this (please note this excludes any JDI, BUA, etc..);
Team A has a velocity of 20 pts per sprint, they are planning to include stories made up of ten 1pt stories and five 2 pt stories. In this case we know that for the team to know an item is a 1pt or 2pt story they must have a clear idea of what is required to get the job done and the cone of uncertainty is virtually nothing. Based on the size of the stories I would recommend either no buffer or a very, very small one.
Team B also has a velocity of 20 pts per sprint, but their stories are individually larger in size, they have a 10pt, 5pt, 3pt and two 1pt stories. As there is a element of uncertainty surrounding the 10pt, 8pt and 5pt stories, I would recommend that the team builds in a greater safety buffer than Team A as there is an increased chance of there being more unknowns that will occur whilst the team is working on these larger stories.
How do we determine what the size of a safety buffer should be based on the stories being considered for a Sprint? This would require the Scrum Master to keep track of the teams points estimations and then at the end of a sprint note how big an item of work actually was, you then can use this figure as a multiplier for future stories of the same size.
For example if when a team plans a 10pt story, they actually take 12 points worth of effort in Sprint 1, then in Sprint 2 they take 14pt’s to deliver a 10pt story you have a multiplier of 1.3 for a 10pt story. If the team selects a 10pt story in a future Sprint your safety buffer would be 3pts.
I specialise in all things Agile (XP, Kanban, Lean), in particular Scrum. I have a passion for taking on 'problem' projects / teams and turning them into a sucess as well as promoting automated test driven practices.






