When I help teams implement Agile methods, I find that some folks have a hard time getting their head around “estimating” user stories (aka, requirements) using story points. When I get to the discussion of Sprint Planning where we are scrubbing stories (aka, requirements) as a team, I used to say it is now time to “estimate user stories”. I would emphasize the importance of having the whole team estimate the story together. I also tend to apply the planning poker technique where each team member has a physical or virtual set of cards with the Fibonacci sequence (aka, law of distribution) of numbers on them (e.g., 1, 2, 3, 5, 8, 13, 21, 34, 55, etc.). When it is time to estimate the user story, each team member selects a card from their deck relating to the story points they think reflects their estimate of the work which should include their notion of complexity and risk for that story.
When I educate folks on estimating user stories, some folks ask me to align the story point with days or hours. That’s when it occurred to me… I realized that when I use the word “estimate” it would make some (many?) folks think of the traditional estimation that uses “schedule” as a measure (e.g., hours, days, weeks, months, years). However, in Agile the intent is to size the amount of work based on the functionality you are building for that story. So in effect in Agile, “scope” is the measure of progress. This is when I realized that folks were often trying to apply a schedule measure because of their familiarity with traditional estimation when in fact, story points is meant to represent the size of the functionality we are building or the scope of the work including the amount of work + complexity + risk of that work. In other words, it was like comparing apples and oranges.
With this in mind, I strongly advocate that in Agile it is much more meaningful and appropriate to use the term “size” as the verb to measure the user stories since this relates to the amount of functionality you are building. This is more than just semantics. This takes us a step away from the traditional mindset where schedule is “king” and moves us to the more important focus of scope since to our customers, the functionality is what is valuable. Now make no mistake, there will be trades offs between schedule and scope, but working software that meets customer needs and provides them value is IMHO slightly more important (e.g., working software over schedule).
It is also important to note that a team’s sprint velocity is a representation of how much functionality can be delivered within a sprint. This is yet another reason why I encourage you to use the term “size” since sizing individual stories relates to the functionality you are building and the sprint velocity relates to how much total functionality is delivered in a sprint.
So if you are having trouble understanding or explaining the concept of estimating user stories, think in terms of the scope of functionality and consider using the term “size” instead of “estimation” to break from the traditional mindset of schedule. So maybe size does matter after all…
When I educate folks on estimating user stories, some folks ask me to align the story point with days or hours. That’s when it occurred to me… I realized that when I use the word “estimate” it would make some (many?) folks think of the traditional estimation that uses “schedule” as a measure (e.g., hours, days, weeks, months, years). However, in Agile the intent is to size the amount of work based on the functionality you are building for that story. So in effect in Agile, “scope” is the measure of progress. This is when I realized that folks were often trying to apply a schedule measure because of their familiarity with traditional estimation when in fact, story points is meant to represent the size of the functionality we are building or the scope of the work including the amount of work + complexity + risk of that work. In other words, it was like comparing apples and oranges.
It is also important to note that a team’s sprint velocity is a representation of how much functionality can be delivered within a sprint. This is yet another reason why I encourage you to use the term “size” since sizing individual stories relates to the functionality you are building and the sprint velocity relates to how much total functionality is delivered in a sprint.
So if you are having trouble understanding or explaining the concept of estimating user stories, think in terms of the scope of functionality and consider using the term “size” instead of “estimation” to break from the traditional mindset of schedule. So maybe size does matter after all…
Interesting approach and thank you for sharing. I left estimate as it was and let the team estimate on complexity compared to the other stories, so that the team does burn complexity, but I somehow stumbled into the same confusion about the words.
ReplyDeleteI have not blogged about it (yet), but maybe one day under this label: http://socialea.blogspot.dk/search/label/complexity
Hi Mario
ReplyDeleteYour problem is just asking to “estimate user stories”; estimating is a technique to come to some sort of metric but it needs to be based on something. You would be better to ask "estimate the size and complexity of the user stories".
This may produce the response 'what do you mean by size and complexity?'. Mike Cohn has a good explanation; see http://www.mountaingoatsoftware.com/blog/its-effort-not-complexity.
The next problem you may be having with people understanding story/planning points is that your decription does not include the relative nature of the Planning Game/Poker technique. If you ask someone just to say how many points to a User Story, they are bound to ask what does this number represent and they will always think time because that is what they are used to! Story/Planning Points are relative measures; choose what everyone considers the easiset and then compare all otheres to that one.
The problems that cause you to ask for different language around 'estimating' are not the root causes of confusion; it is the incomplete usage of language, a probable incorrect implementation of Planning Game/Poker and the fact that 'common' words have different definitions to different people.
So I do not agree with your suggestion about using 'sizing' instead of 'estimating'. Explain what the process is and make sure that whatever name you give it is completely understood by those carrying out. Call it 'fumbledoodling' - the name doesn't matter, the understanding of the technique does.
I have to disagree with this comment. What Mario is trying to do is get away from the baggage of the word 'Estimate' by using the term sizing. Yes, what we are doing is estimating in the true sense of the word, but from years of waterfall baggage and estimating in hours, that term is so overloaded that it is far easier to just re-label it. We have used the same concept of sizing for some time now and it really helps people get past the hangup of an hours to points comparison.
DeleteThanks Dwayne for helping clarify my thought!
DeleteI had to think about a presentation I recently watched, it was called Want better estimates? Stop estimating! It's on the infoq website, but that's currently in maintenance, but google it later.
ReplyDeleteThe thing that interested me there was the different goals or terms that are related to estimating. We (as humans in general) tend to combine everything into this one word, while in fact there's more to it. An estimation is a prediction, but generally we think as it as a target (somehow it becomes reality as soon as we said something about it) and as commitment (2 days, great I'll get the results by the end of the week then!). Real estimation is always guessing to some degree, sure we can guess relative sizes better, but you don't know until you did it. I think it's useful to call it differently as some of those additional meanings of estimation are not so apparant anymore.
Nice article!
Good comments! I appreciate the input!
ReplyDelete@Kai - if you blog about it, please let me know. I look forward to the read.
@Steve, yes for certain you need to explain the full process behind what you are doing.
But what @Dwayne mentions, there is so much waterfall baggage with the word estimate that as soon as you say the word, people are already thinking in terms of hours, days, etc. So why not start with a term that people assume less and are willing to learn?
@Andre, yes, we need need to acknowledge that we are guessing to some degree although with story points context and our empirical data, the guess (hopefully) gets better and better. Cheers!
Hi all, I always read estimating/sizing stories with points rather than hours, but never get my head around if in a Sprint of 2 weeks I have 60 hours of total team commitment and product backlog as below,
ReplyDelete2 stories each 3 points,
3 stories each 8 points,
4 stories each 5 points and
2 stories each 13 points
then without assigning hours to user stories how would I move stories from backlog to current Sprint. Would highly appreciate your comments/ guidance.
Regards,
ScrumMaster
@Riaz, I think that depends on your velocity (not exceeding the total story points that are delivered in your previous scrum)
DeleteWhenever i come across such nice blogs,It creates an awesome feeling inside me.Interesting approach and thank you for sharing. I left estimate as it was and let the team estimate on complexity compared to the other stories, so that the team does burn complexity, but I somehow stumbled into the same confusion about the words.It is a heart appreciation by a Hot Pakistani Girl.
ReplyDeleteHappy to see such a nice discussion on this article.. Sizing (always relative) is the best practice suggested though, but in my opinion, defining thin and right sized stories is more important. This help clear understanding of the functionality and so can achieve the accuracy in estimate or sizing.
ReplyDeleteThanks HPw and Vijji for your thoughts!
ReplyDelete