Tracking Unfinished User Stories

In the previous few articles we covered the importance of a well refined Product Backlog, what a User story is, how Story Points are useful in estimation and many other aspects of a Scrum Project. Let’s assume that all of the prerequisites have been taken care of and the team has started work on the first Sprint on a few user stories. It is a very real possibility that a user story that the team started in a sprint were unable to be completed for some reason. How would you handle that situation?

Why this Article?

Scrum Explicitly Recommends that each scrum team only pick up so many user stories as they can finish in a Sprint. By finish they mean develop, test, integrate and all those activities that happen before a story can be shipped as a usable feature of the product to the customer. Scrum also recommends that the scrum team and the product owner work together to break-down larger story/feature requirements into smaller pieces that can be individually implemented in a single sprint.

In an ideal world all user stories can be split into small pieces and the scrum team will finish all of its user stories by the end of the Sprint.

The real world paints a very different picture. In any actual scrum project, it is inevitable that you end up in a situation where the team was unable to finish one or more user stories they started during the sprint. So, if this happens, what do you do? That’s what this article is about.

Of course – there is no Right or Wrong way of handling this situation. Scrum doesn’t officially endorse or recommend either of these approaches. As a self-improving team, Scrum expects the team to work together to identify a suitable solution that everyone agrees to handle such instances and deliver a workable product at the end of each sprint. I have tried all of them during different projects and have listed down the Pros and Cons based on personal experience. You are free to choose the approach you wish to take for your scrum team.

Option 1: Move the Entire Story to the Next Sprint

This seems to be the most straightforward approach where, if a story isn’t finished fully, we just move it forward to the next sprint. Simple – right?

As always, the Product Owner is the deciding authority in such a situation. If there are other newer/higher priority stories that are yet to start, the Product Owner may choose to ask the team to hold-off on continuing work on this WIP story and start the others instead. In which case, this story will be paused at hits unfinished state and pending prioritization for one of the future iterations. Alternately, if this story is important enough, the work will continue and the team can finish the story in the next Sprint.

Pros of this Approach:

1.     Simple & easy to implement
2.     Scrum Team will be ok with this approach as it allows them to continue working on a story without having to worry about finishing it in the current Sprint
3.     Follows Scrum guidelines where a story that isn’t completely finished is not counted toward team velocity.
4.     Easier for the Scrum Master as he doesn’t need to track story progress on a per task basis to identify how much work was done in a sprint and how much is pending.

Cons of this Approach:

1.     Teams Sprint Velocity becomes inaccurate. Let’s say there was a 10 SP story that was started in Sprint 2 and the team couldn’t finish and move it to Sprint 3 and finished it. Now, this 10 SP gets added to the Sprint 3 velocity but that isn’t entirely true. Of the 10 SP only a portion of the work was finished in this sprint. If the team has more than one user story like this that got carried forward the velocity for Sprint 3 may go up significantly while the actual amount of work done by the team was much lower.
2.     Unfinished stories may get piled up if other higher priority items get started in the future sprints
3.     Status Reporting to Management becomes tricky as the teams productivity for sprints doesn’t include unfinished work. Let’s say in Sprint 2 team finished 90% of a story by spending 18 days of effort and only 2 days’ worth of effort is pending to mark the story as completed. If the story gets moved to Sprint 3, the eventual productivity of the team for Sprint 2 does not count this effort that was already spent on the story.
4.     Some Teams may take advantage of this flexibility to carry forward user stories and end up underperforming during sprints thereby impacting overall product quality/features/timelines.

Where this Approach may be most suited:

1.     This approach could be suited where every story is an independent workable/usable product feature and can be individually prioritized by the product owner
2.     For internal projects where customers are other departments and not paying customers who expect accurate progress/status updates at the end of every sprint
3.     For Organizations where the management is willing to allow a certain level of freedom to the scrum team to finish their work in coming iterations without becoming nervous about the reduced velocity in a certain sprint if stories went unfinished.
4.     For organizations where the product owner has a well-defined priority order that doesn’t change every iteration thereby allowing team to finish up WIP stories in 1-2 iterations time

Option 2: Split the Story to Carry-forward only the Unfinished part to Next Sprint

After reading the Cons listed above for the “Move the entire story” approach, if you are thinking this isn’t right, this option would be very appealing to you.

The idea here is, we understand how much work corresponding to the story has been completed and then split the user story into two parts. One part corresponds to the work that was completed in the current sprint and the other corresponds to the pending work. The story point size also gets split based on the % complete. If a 10 SP story was 50% complete in a sprint, each split of the story will be 5 SP in size. Straight forward right?

Pros of this Approach:

1.     Team Velocity represents the volume of work finished by the team
2.     Status reporting becomes easier as all completed work items are represented in the current sprint’s productivity & outputs.

Cons of this Approach:

1.     The Intended Purpose or Meaning of the term Velocity becomes Ambiguous. If you go back to the article on <link>Velocity, we had talked about the features the team was able to complete fully in a sprint counting towards Velocity. If a story is partially finished that means the feature isn’t fully usable or shippable to the customer of the product.
2.     Completed Stories in the Backlog may not really be Ready for Acceptance. Any user story that is complete technically means the product owner can accept the same and mark the feature as good enough to be shipped to a client. With this story split approach, completed stories represent partial features only and would require the missing features to be implemented in the subsequent iterations before we can mark a feature as a whole as “Ready for Acceptance”
3.     Added complexity of tracking tasks in the story on their accurate completion % before stories can be split appropriately. This adds a little bit of overhead for the scrum master as well as some senior members of the scrum team who are also playing roles as team leads.
4.     Easier for Status Reporting as every iteration will definitely have a certain amount of work finished by the team and also avoids the spikes & lows in team progress reports. If stories were carried forward sprint 1 could show a very small SP output while sprint 2 could show a high SP output due to carry forward stories.
5.     Pushes the team towards trying to mark stories as completed for the sake of boosting velocity. If you go back to my article on <link> velocity, one of the things that scrum teams shouldn’t do is, try to wrap up user stories for the sake of boosting the velocity.

Where this Approach may be Most Suited:

1.     This approach could be suited where stories are interdependent on one another and need to be finished collectively for a workable/usable product feature and prioritized collectively by the product owner
2.     For external projects where customers are paying customers who expect accurate progress/status updates at the end of every sprint
3.     For Organizations where the management prefers to know exactly how much work was completed by the team every week (or Sprint) and gets nervous when stories aren’t marked as completed when a Sprint ends.
4.     For organizations where the product owner has a well-defined priority order that doesn’t change every iteration thereby allowing team to split up the stories and finish them across 2-3 iterations time
5.     For teams with experienced scrum masters who can use their experience & judgment to guide the team about how to assess completed work as well as split stories appropriately
6.     For teams where the team members have experience working in scrum projects and wouldn’t push to mark a story as completed just to boost up the velocity.

Option 3: Rewrite User Story to reduce scope to finish user story in Current Sprint

Though the title sounds simple enough, this option is quite frankly the most complex (of the 3 options of course) and requires a lot of intervention from the product owner towards the latter part of the Sprint.

If a team is unable to finish a user story, we can work with the product owner and the team to cut down on the scope of the story to keep only the bare minimum features the team can finish in the current sprint and then request the product owner to create a fresh user story for prioritization for one of the upcoming iterations.

The complexity arises over the fact that, not all stories can be broken down like this to allow the team to mark a small subset feature as complete. If this was in fact doable, the question that begs to be answered is, why didn’t the team (including the PO) do it during the sprint planning or prior to that?

Anyways, even if teams don’t explicitly try to break down stories/features into smaller chunks, if we try to ask them to rewrite the stories (or further break them down) toward the end so we can mark stories as “Completed” in full, the discipline on creating efficient and concise user stories would happen automatically. If I were the product owner and am being asked by the team to break my story into a bunch of smaller pieces toward the end of the sprint, I may as well do that in the beginning to avoid double effort – right?

Pros of this Approach:

1.     Follows the Scrum guidelines of finishing a user story in an iteration
2.     Allows the scrum team a certain level of flexibility/freedom because pressure to finish a story in a Sprint may sometimes be counterproductive.
3.     Sprint/Team velocity retains its intended meaning and represents the usable features delivered by the team in a sprint

Cons of this Approach:

1.     Quite complex and difficult to implement. Not all stories can be split or broken down into smaller pieces. If a feature/story cannot be broken down further, we may need to use the options 1 or 2 we discussed above
2.     Some Teams may take advantage of this flexibility to carry forward user stories and end up underperforming during sprints thereby impacting overall product quality/features/timelines.
 

Where this Approach may be most suited:

1.     This approach could be suited where every story comprises of a set of independent workable/usable product feature(s) and can be further broken down by the product owner
2.     For internal projects where customers are other departments and not paying customers who expect fully usable/workable features at the end of every sprint
3.     For organizations where the product owner is very experience in scrum practices and has the business knowledge to break down every feature/story into multiple smaller pieces.

Some Last Words:

Like I said at the beginning of the article, all these approaches have their own Pros and Cons. Scrum does not mandate us to use either of these approaches. In fact, you are free to add options 4, 5 or even 6 if you think that might help avoid (or handle) instances where stories remain unfinished at the end of a Sprint.

If you have other ideas to handle such situations, do feel free to sound off in the comments section for the benefit of the others.