Don’t Give Partial Credit

What do you do with stories that don’t finish before the end of the sprint? Do we get partial credit?

I’m asked that a lot. Everyone wants to know whether to split the story and what to do with the points. Don’t give partial credit for unfinished stories or make untestable splits.

Don’t Bother Splitting Unfinished, Untestable Stories

Move unfinished, untested stories to the next sprint, without splitting. What benefit would come from splitting?

Sometimes people tell me that in the future they will need to know what work was done in this sprint, so that’s why they split stories. I’ve never seen the need to do that. If that question does arise, your agile tool’s history will show what you need to know.

It’s too easy to make these lousy splits. Every user story must be a proper user story. Don’t get sloppy. Slitting a story into an unfinished and untestable portion is sloppy. It’s a bad habit that will begin to show up as poor stories in your product backlog. You have to be disciplined at being disciplined.

Don’t Give Partial Credit

Others tell me that they want the velocity to look right for this sprint, to take into account the work they did on the unfinished story. They want partial credit. Bad idea.

Once you’ve begun development, once you’ve done some design and dug into the detail, it’s difficult to correctly estimate a piece of a story relative to other stories that you haven’t started developing yet. For a longer explanation of this, see the post Don’t Estimate In Sprint Planning. It’s difficult to correctly estimate such work relative to the rest of the stories in your product backlog, those that you haven’t started working on. It’s especially hard if you are trying to estimate some poor split to an unfinished story, a piece that doesn’t meet your definition of done. Just don’t do it. Just move the whole story to the next sprint.

I do, however, recommend adjusting the estimate on the story downwards (never up) if the estimate of the remaining work is smaller than the original estimate. I care a great deal about being predictable, about conservative planning, and about not overstating my velocity. The problem with giving all the points in the next sprint (n+1) is that it makes the recent average velocity (usually over 3 sprints) be too high a month and a half later when this sprint (n) drops out of the average. A month and a half later no one will remember that we carried over all the points for some story into that next sprint. No one will realize that the velocity they are using to evaluate their release plan is abnormally high.

In Fact, Don’t Give Credit at All

Others tell me they want to get credit for the work done on the story.

I teach against the notion of “partial credit”. I teach against the notion of getting credit in general. There is no credit. It isn’t about getting credit. That’s the wrong way of thinking about velocity. Dangerous even.

Velocity is a tool to help us with release planning. If the team feels they need to get credit, there is dysfunctional behavior in the organization. Perhaps teams are being challenged to increase their velocity, or are reprimanded if their velocity dips, or are being compared against another team’s velocity. If the team feels they need to get credit, they will game the numbers and velocity will not be useful for its intended purpose.

Velocity is what it is. It’s not about credit.

A Better Plan: Finish Sprints Cleanly

In training, I make a big deal about the problem of unfinished stories. Whatever you do, however you handle them, unfinished stories are difficult to deal with and they mess with your velocity. There is no good solution other than finishing sprints cleanly.

Better than knowing the how to handle unfinished stories is to not have unfinished stories. Don’t start work you can’t finish in the sprint. Before starting any story, first see if the team agrees that it and everything else already started can be finished cleanly.

Stop starting and start finishing

That was coined by David Anderson, right? It means to focus on finishing stuff that is already started before starting new work. Scrum teams can learn a lot from David. Study his books on Agile Management and Kanban.

Each day, before starting work on another user story, the team should consider whether it can finish all other in-progress work and this additional story before the end of the sprint.

In the last half of a sprint, the team should start asking whether there is anything they need to pull out so that they can swarm and finish the other stuff cleanly. If it looks like multiple stories aren’t going to make it, sacrifice one or two stories, stop working on them now, split them appropriately (see below) or throw them out of the sprint, so that you can finish all the other stories cleanly.

Split Splitable Stories

There is a scenario in which I would split an unfinishable story, but you should do that before the last day of the sprint, both halves must meet the INVEST criteria, and the done half must fully meet the definition of done.

Sometimes this happens when the team has a story generally working and tested but is having trouble with some particular error scenario or some advanced usability issue. I’ll split it into a basic and advanced story, or a happy path and an error handling story. But I will always split such a story so that both parts meet the INVEST criteria. They must both be true User Stories. And the part that is done has to meet the definition of done and be accepted by the product owner.

In that case, I might split the points if the team can decide how to allocate the points. (But never such that the total is greater than the original.)

Conclusion

So there you have it. Any time you split a story, for whatever reason you split it, make sure each half is a proper user story, meeting the INVEST criteria. Don’t cause velocity inflation and risky release planning by increasing the total points on underestimated stories. Finish sprints cleanly. And just forget about trying to “get credit” for unfinished work.