A.k.a. Story Points
allow us to separate Estimation from Commitment
Story Points vs. Ideal Days
Story Points are an estimate of the Size of the Story. Where
Size is the combination of Complexity, Effort & Doubt:
- Complexity – Difficulty, hard algorithms, complex logic extra, abstract concepts.
- Effort – Raw effort / grunt work. I.e. Making a simple parameter change to hundreds of similar method calls.
- Doubt – Uncertainty around how will we build it or what it is that we need to build.
Ideal Days or Ideal Hours is an estimate of how long it will
take to complete the Story.
So while Story Points are made up of a single element:
‘Size’, Ideal Days are made up of two elements: ‘Duration’ and ‘Size’.
Story Points cannot be equated to Ideal Days/Hours because
they are made of different elements. i.e. Size vs. Duration & Size.
Here is an example that illustrates my point
Story A is estimated by the team to be 1 Story Point. Story
B is estimated by the team to be 8 Story Points. Suppose that we get our two
brand new graduates to work on Story A, while our two experienced Senior
Developers work on Story B. Story A is completed in 5 working days, Story B is
also completed in 5 days. Now suppose that we had given Story B to our new
graduates, while our experienced Senior Developers worked on Story A. In this scenario Story A is completed in 1 day, while our graduates will struggle on eventually delivering Story B after 30 days! While the Size of the Story remained the same the Duration to complete them varied dramatically based on who worked on the Story.
graduates, while our experienced Senior Developers worked on Story A. In this scenario Story A is completed in 1 day, while our graduates will struggle on eventually delivering Story B after 30 days! While the Size of the Story remained the same the Duration to complete them varied dramatically based on who worked on the Story.
Estimation vs. Commitment
We use Story Points because it allows the team to focus on
estimating one element; the Size of the Story. When sizing the Story we do not
have to consider Who will work on it, or consider Committing to the Story.
During Sprint Planning we decide which Stories to Commit to
the Sprint Backlog. This is where the team considers who will work on which
story; hence combing the elements of Size, Who & Duration.
Estimating in Story Points allows for Estimation and
Commitment to be separated, giving better results for each.
Interested in estimation?
- Fast Estimation
- Story Points are only one third of the reason to estimate
- Top Tips for Planning Poker
Training available in South East QLD, Australia
If this article was interesting to you, then your team would
likely benefit from face to face training on Agile Estimation. I run a one-hour
Agile Estimation training session, that is highly interactive, immensely fun
and teaches the foundation of agile estimation along with how to effectively
run Planning Poker as well as Fast Estimation. Please contact me to set up a
training session for your team: andrewrusling@hotmail.com
Thanks for the great explanation! On the commitment part, though, the approach you've described works when a commitment is limited to a single sprint which is not always the case.
ReplyDeleteHi Dmytro, I am glad you like the explanation. I only get teams to commit on a Sprint by Sprint basis so it works for me. Do you get teams to commit across multiple Sprints? i.e. Committing to a Release Backlog?
ReplyDeleteI found this post as I was looking for additional insight for the blog posts I was writing on estimation. I had already planned a blog post on story points, so I didn't want to comment until I had finished it. Since it went live today I finally am ready to comment. As I read this post it gave me an idea for another post on story points which I hope to have up by the end of November.
ReplyDeleteYou hit the explanation of the why on story points versus time just about perfectly. One thing I found useful, especially for the team new to Agile and estimation, is to further emphasis that story points are not time by obfuscating it further and dropping the number part off of story points. I am not sure if you allow links, but the post is here: http://ouragilejourney.com/2013/11/05/story-points-should-not-be-numbers/.
I look forward to catching up on more of your posts over the next few weeks. The more time I spend learning about Agile Methods the more I realize that nobody will ever be done learning about them and we can all learn from each other.
One of the benefits that comes from Story Points is adding them up to determine velocity, then using velocity to predict when a backlog of work will be completed.
ReplyDeleteRemoving the numbers, removes this benefit. This is why I go through the extra effort of mentally separating Story Points from Hours, for the teams I work with.
I am glad you take pride in what you write. This makes you stand way out from many other writers that push poorly written content. designs
ReplyDeleteI’m going to read this. I’ll be sure to come back. thanks for sharing. and also This article gives the light in which we can observe the reality. this is very nice one and gives indepth information. thanks for this nice article... grief
ReplyDeleteAppreciate your bllog post
ReplyDelete