So the question now is what do you do with the story points? well - the team did not finish the story, so you get zero points for it in the current sprint (cries). The story is now moved to the next sprint and keeps the same story points... not so fast tiger. Lots of things are happening here - so lets take a minute to think about it.
The best way to study this problem is to do it by example. Lets say you have a simple user story, all the development was done but you just ran out of time to do proper testing and code review (which is part of the definition of done). Still the story works, but it is not meeting the definition of done. Lets say that story was estimated as 3 story points, is it still 3 story points? Not really. We did most of the work, we just need to test it and we feel confident that it will get done in a few hours or one day, there is really not much complexity in this story anymore. The best thing to do is simply to put it back in the backlog like all its other friends and re-prioritize it and re-estimate the story point based on all the new information we have learned. We might now estimate the story as 1 point, and maybe there are now more important stories to do, and it doesn't even make it to the next sprint but the one after that.
Wait a minute, did I just lose two points here? The user story was estimated as 3 points, it didn't get done so we got zero (cries) and now it is one point? (more cries). I feel robbed where is my money go? How did all of a sudden a 3 story pointer got into a small 1 pointer. Well, you didn't get robbed in fact you gained. Let me explain...
if we look at user stories and story points, we normally find ways to convert them to cost. A lot of story points means more complexity, more time and more money. A set of features with 100 story points will take more time to do than a set of features with 10 story points. So when we bring our story points down from 3 to a 1, we really just got a rebate on the cost of the story. More like a promotional cost because we learned and we know more now. Still feel robbed? OK how about this then...
If we look at a product release backlog, it might have many stories there with a large total. For example 700 story points to get to the release. If stories don’t get done and get moved to future sprints and are now estimated less, your road to release just got shorter. See! you are not robbed. You just have to walk or run less to get to the finish line.
Sometimes stories don’t get done because of another reason altogether. The devil lives in the details, details we don’t see at first glance. So once we started working on the story we find out there is way more to it, and it is much more complex. Basically it was under-estimated. Still, the story does not get done but this time the team decides the story is worth more points. What now? Its still a win, because you learned this on time and now you can adjust. Normally in cases like this the story should be broken up, to smaller stories. Sometimes even a spike story, just to de-risk some of the unknowns. Still, the same thing should happen. The story is put back in the backlog and re-estimated and re-prioritize. In this case, I would add, it is also broken up and groomed. One thing I would not do, is just keep the same story point and blindly put it in the next sprint. If you gain knowledge and information during a sprint its a win, and you must translate that win into a new estimate of that story.
For the same reason, I also believe stories should be re-estimated again and again. As the project moves and as time goes by, we learn more. Things that seemed complex back then can be simple now. No reason not to re-estimate stories again. Its just the agile way of things...
No comments:
Post a Comment