In my previous post, I highlighted the other side of the “Done” contract, by looking at what happens when sprint teams “Carry Over” unfinished user stories from one sprint to another. In this post, I will cover three possible options for tracking and managing unfinished stories, with an emphasis on how this would specifically impact a product backlog.
As with all things, the size and personalities of you team can impact how you handle unfinished user stories, but even with that in mind, it is surprising how many differing opinions there are out there. I came across a posting in the programmers section of StackExchange that highlighted this very question.
In this post, the writer lays out three options for handling a scenario when a feature team only partially completes its work on a user story.
- Award partial story points for what has been done, and adjust the size down of the original story, based on an estimate of what work remains.
- Close the unfinished story, award no points, and create a new backlog story for the remaining work
- Skip A and B, but do create a new story to size during the next sprint planning meeting.
The issue with Option 1 would be that it is pretty uncommon to award any story points for an incomplete story. This would misrepresent the velocity of the team because points would be estimated twice, once at sizing, and then again mid sprint. Option 2 is reasonable, but possibly not worth all of the backlog adding and subtracting. Another problem with 2 is you may lose context between story 1a and story 1b. Plus it adds in the concept of fractional stories, which further confuses the issue.
If it were me, I would leave the user story that wasn’t completed open. I would update it with a clear description of what was done and what we think we have left. The story would then go back into my backlog, original story points intact and un-awarded, and wait for to be prioritized for the next sprint.
Ideally the backlog would only consist of stories that are finite pieces of work. The smaller the story the better. If my team is finding that there is a lot of carry over, either we are over-committing in terms of the work we can accomplish each sprint, or our stories are not atomic enough to work on individually. These questions are key to understand before moving forward. I may need to recalculate my team’s velocity, or work to further disaggregate the stories in our backlog into smaller, more modular tasks.
By lowering our velocity, I’m communicating out that we need to spend more time on fewer items to deliver consistently. Doing this may help us refocus and reduce unfinished work. If this alone doesn’t do the trick, and I am constantly having to carry over large stories with many story points, the nuclear options of further splitting the backlog may be necessary.
Either way, business value and root causes should guide you in dealing with these carried over stories. Maybe stories are being carried over because they aren’t essential to work on right now, thus they are always left til the end?
Who knows, but if the business value is high, it’s perfectly reasonable to include the item in the next sprint. After all, isn’t that the point of Agile in the first place? Things change, and as we learn more about the domain, our business needs, and how to translate opportunities into working code, it’s essential that we route our conclusions back into the planning process for the best possible results.
