Story Points, Lean Principles and Product Development Flow
Из ленты: Ivar Jacobson International » Ivar Jacobson International
A “story point” is a unit or measure which is commonly used to describe the relative “size” of a user story (an agile requirements artifact) when it is being estimated. In many cases, a fibonacci sequence of 0,1,2,3,5,8,13,21,… is used during the estimation process to indicate this relative size. One of the reasons for this is to increase the speed in which an estimation is derived. For example, it’s more difficult to agree on the differences between a 5 and a 6 than it is to agree between a 5 and an 8.
It is very common for agile teams to use story points to describe the “level of effort” to complete a user story. That is to say a user story estimated at 5 points should be expected take 5 times as long as a user story with a point of 1. On the other hand, it is also very common for people to include effort, risk and uncertainty (or complexity) in the definition of a story point. That is an 8 is also 4 times riskier than a 2, 4 times more uncertain.
Mike Cohn has stated that it is a mistake to do this:
“I find too many teams who think that story points should be based on the complexity of the user story or feature rather than the effort to develop it. Such teams often re-label “story points” as “complexity points.” I guess that sounds better. More sophisticated, perhaps. But it’s wrong. Story points are not about the complexity of developing a feature; they are about the effort required to develop a feature.”
So what do we do with this?
In Donald Reinertsen’s groundbreaking work “The Principles of Product Development Flow” we get a clear sense about how “batch sizes” affect our product development flow. Without going into much detail, it is fair to say that story points describe the “batch size” of a user story. Web definitions define batch size as: “quantity of product worked on in one process step”.
Reinertsen describes some of the principles of how batch sizes relate to our product development flow. For example: Principle B1 “The Batch Size Queueing Principle: Reducing batch size reduces cycle time”. The cycle time is how long it takes, or, the level of effort to complete the story. Smaller stories equal less effort than large ones. This principle would support the story point as a relative unit of effort as Cohn would suggest.
There are other principles that might not be so supportive of this perspective.
For example, looking forward to the second batch principle: Principle B2 “The Batch Size Variability Principle: Reducing batch size reduces variability in flow” we beging to see some of the challenges in this as a “relative level of effort comparison” only. If we have significantly increased variability in the size of the story, should we still “expect” a “5” to be the same as 5 “1’s”? All we can really expect” is more variability. Increased risk, schedule delays, unknowns are what we should “expect”.
Let’s look at a few more principles.
B3: The Batch Size Feedback Principle: Reducing batch size accelerates feedback.
In our scrum processes, for example, because of B1 (increased cycle time) would mean that the product owner doesn’t see the work product as quickly, and, in some cases, begins to lose faith or worries and increases pressure or interruptions of the team. Fast feedback is cornerstone to agile and product development flow.
Large batches lead to B7: The Psychology Principle of Batch Size: Large batches inherently lower motivation and urgency. We like to see things get done, it makes us happy. As humans it takes us more time to get on with a huge job, but a simple one we might just knock out and get on to the next one.
Very little good comes from large batch size as it relates to product development flow. There are 22 Batch Principles and they are all not too supportive of large batch size.
For example, some of them are:
B4: The Batch Size Risk Principle: Reducing batch size reduces risk.
B5: The Batch Size Overhead Principle: Reducing batch size reduces overhead.
B6: The Batch Size Efficiency Principle: Large batches reduce efficiency.
B8: The Batch Size Slippage Principle: Large batches cause exponential cost and schedule growth.
And so on. Large Stories are bad. Really bad. So, what can we do about this in our agile software development process? The most important thing is that we can not “expect” an “8” to take 4 times as long as a “2”. The “Principles of Product Development Flow” tell us that this is impossible.
We need to understand that, regardless of the size, they’re estimates, and not “exactimates” as The Agile Dad says. We need to accept that our estimate of a larger story is less accurate than our estimate of a smaller one.
We need to understand that, since we can not commit to an unknown, it is unrealistic and violates our lean principle of respect for people to ask them to commit to large stories.
We need to understand how batches affect our queues, our productivity, predictability and flow. We should study and apply product development flow.
We need to understand that we’ll do better in our flow if we have smaller stories, so learning the skills and breaking down stories into smaller sizes will help. We may never allow anything larger than a “5” for example, into a sprint.
With that said, if we have “8”’s in our backlog that (for some reason can’t be broken down into smaller stories) we should compensate in our velocity load estimates for stories in a given sprint. For example: If we have an estimated velocity of 20 and all we have are stories that have been estimated as “8”, we might want to schedule only 2 of these stories in the sprint, leaving us some capacity margin for safety.
One thing to note, however, is that, smaller stories might not be the best solution for geographically disparate teams, according to B17: The Proximity Principle: Proximity enables small batch sizes. Where it might be more effective to have the remote team working on a larger story. They might break it into smaller stories for efficiency. We need to understand the economics of batch handoff sizes and balance our efforts accordingly through reflection and adaptation.
