Our previous installment of Ask an Agile Coach had a new question in the comments:
As for the case when some of the user stories didn’t get completed, what happens to the user stories which were partially completed–say, 80% finished–but didn’t quite make it? How do you keep your velocity metric from getting hosed?
Practitioners have asked me variations of these questions many times over the years. I’ll paraphrase them into a single question:
How do I handle the effect of carryover on velocity?
When we gather data about something, there’s an innate temptation to filter the data to effect a desired outcome. It is often subtle; sometimes we don’t even realize we are doing it. This is a form of sampling bias, a term from the field of statistics. I love this sentence from the Wikipedia article on sampling bias:
A biased sample causes problems because any statistic computed from that sample has the potential to be consistently erroneous.
You handle carryover by letting it accurately affect velocity, whether that effect is positive or negative.
The purpose of tracking velocity is to provide feedback on how well a team can estimate, break down, and execute work within a fixed interval. Carryover implies a need to improve in one or more of these areas. When a team has a drop in velocity, be sure to talk about it in the retrospective. Are stories too big and bulky? Do tasks sit for days on the board waiting for the next handoff? It the team consistently over-committing during Sprint Planning, hoping for unrealistic throughput?
Allowing a skewed velocity sets a team up for disappointing its stakeholders. If velocity looks higher than reality (inflated velocity is far more common than deflated velocity), stakeholders are going to have expectations that cannot be met. Embrace the bad news, and use it to reinforce the message that our only hope is to get better at working together as people.
Barry Hawkins of All Things Computed provides coaching and mentoring in how to successfully apply the process and technical disciplines of Agile Software Development.
I’m still unclear on how you’re proposing to handle the velocity? Would you take all of the original story points in the next sprint (assuming the story is done)? Would you redo the story points for the next sprint with the remaining work?
Thanks for your question Mark! I will respond to it in a subsequent post. I will shoot for getting it out today, I’m overdue for one anyway.
Not to nag, but Mark’s question has me on pins & needles. I suspect the answer is to take the story points out of the previous iteration and take full credit in the following iteration, but I’d like to hear what you think.
Thanks,
Rob
I am so overdue for this, apologies! Been busy with projects of late. To give a short answer, yes, I meant that they carry over. No partial points. A longer answer coming soon. Thanks so much for reading!
Pingback: Ask an Agile Coach: Should I count partially complete user stories in my velocity? | Barry Hawkins
Comments are closed.