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…
