I've attempted to write this article in the inverted pyramid style common in newspaper articles. (Most important info first. Least important last. Quit reading wherever you wish.) Don't know if I succeeded. What do you think? How badly does this stink?
A mistake I've seen is to use lead time metrics, derived from the development of small, well-split stories, to figure out how long it will take to complete a backlog full of raw unsplit stories. Apples and oranges. Don't do that.
Writings about the Kanban Method eschew story estimation as being both waste and inaccurate. Even relative estimation. So instead, they recommend understanding your system well and gathering the metrics on average lead time. With that data you can compute how long it would take to complete a backlog of work. Even some Scrum teams are beginning to use this approach. I like this method.
But to use this approach you must truly understand your system. I'm talking about understanding the behavior of the system and in particular the actors in the system.
For example, it's common to split stories once they get higher in priority and closer to development. That's a good thing and it happens in Scrum and in Kanban. This refinement may happen many times to a story during it's lifetime. I guess that most teams are completely unaware of just how many times stories are split along the way. Often I see stories indirectly split; Setting out to rewrite a set of stories, the set will be thrown away and a new set written, with no one noticing that there are more, and finer grained, stories in the new set.
A similar effect happens in Scrum when teams estimate defects and include those points in their velocity. They most often have no estimate for defects that have yet to be discovered (neither in quantity nor magnitude of effort). If a significant number of new defects are coming in all the time, then such teams are inflating their velocity and underestimating the magnitude of their backlog. This is a recipe for disaster. Such teams wonder why they never hit their dates. Others blame it on a quality problem.
As an aside, any commitments regarding the completion of the backlog have to be in concert with the stability of the backlog. You need to compute a new end date whenever the backlog changes. But that's the same whether you are using lead time or relative estimates with velocity.
Writings about the Kanban Method eschew story estimation as being both waste and inaccurate. Even relative estimation. So instead, they recommend understanding your system well and gathering the metrics on average lead time. With that data you can compute how long it would take to complete a backlog of work. Even some Scrum teams are beginning to use this approach. I like this method.
But to use this approach you must truly understand your system. I'm talking about understanding the behavior of the system and in particular the actors in the system.
For example, it's common to split stories once they get higher in priority and closer to development. That's a good thing and it happens in Scrum and in Kanban. This refinement may happen many times to a story during it's lifetime. I guess that most teams are completely unaware of just how many times stories are split along the way. Often I see stories indirectly split; Setting out to rewrite a set of stories, the set will be thrown away and a new set written, with no one noticing that there are more, and finer grained, stories in the new set.
A similar effect happens in Scrum when teams estimate defects and include those points in their velocity. They most often have no estimate for defects that have yet to be discovered (neither in quantity nor magnitude of effort). If a significant number of new defects are coming in all the time, then such teams are inflating their velocity and underestimating the magnitude of their backlog. This is a recipe for disaster. Such teams wonder why they never hit their dates. Others blame it on a quality problem.
As an aside, any commitments regarding the completion of the backlog have to be in concert with the stability of the backlog. You need to compute a new end date whenever the backlog changes. But that's the same whether you are using lead time or relative estimates with velocity.
Interesting thought tweet from Ian Mitchell https://twitter.com/dr_ian_mitchell/status/243457237224390657
ReplyDelete"My 2c: Story splits help liquidity, but don't confuse that with productivity"
Maybe I should have titled the post "Story Splitting a Kanban Hazard"