How to manage unfinished stories at the end of a sprint

A very common situation I’ve noticed while working with 2-week sprint iterations and agile teams is that sometimes we find ourselves unable to close down all of the user stories by the end of the sprint. In my early days as a product owner I used to get very insecure when such things were happening because I though it would reflect poorly on me.

Nowadays, I have a different perspective. Instead of looking to point fingers, I try to understand why the team hasn’t been able to deliver the full sprint commitment. Here are some questions I like to ask:

- Is this an isolated case? Has this been happening constantly in the last few sprints or are we talking about a one time exception?

- How many user stories were not delivered? There is a difference between missing a small bug fix vs. missing 3 user stories all-together that were representing a whole piece of functionality.

Here’s the model I am currently following when I have to deal with remaining user stories at the end of a sprint.

1.    Identify as early as possible which user stories won’t be finished on time.
Whether it is that the testing part won’t be completed on a particular story due to the fact that development took longer than expected, or the team finds itself completely unable to start working on one or more user stories, the effect is always the same: the sprint’s initial commitment won’t be fulfilled. As a Product Owner, try to predict as early as possible that the team might fail to deliver a certain user story.

2.    Take note of every user story present in the initial sprint commitment that won’t be delivered this sprint
It is important to write these user stories down somewhere, so that we can easily bring them up later during retrospective. While everything is still fresh, have one of the engineers working on these stories add a comment with the reason why it cannot be completed by the end of the current sprint.

3.    Discuss during Retrospective
Start the retrospective with a quick analysis of these user stories that were not completed. Why did it happen? Here are some reasons that come to mind.
- The team failed to properly estimate the effort in the beginning. Why is that? Maybe they aren’t too familiar with some technical aspects involved. Think about providing them the needed support to overcome such issues in the future. 
- The business requirements weren’t clear. Maybe you as a product owner failed to grasp the whole complexity of the requirements and left out some parts that were later discovered by the dev team and required extra effort.
- Other user stories were added during the sprint, because of some urgent business requirement. While this shouldn’t happen at all when applying scrum by the book, in reality it happens that a senior stakeholder asks for a very urgent fix that simply cannot be postponed. In this case, the team might have to deprioritise a different piece of functionality.

4.    Learn from experience and improve
No matter the reason behind, it is our duty to learn from every ‘agile’ experience. We should always think about ways to improve our daily / weekly processes and take time at least every two weeks to reflect upon what went wrong and could be improved in the future. My advice is to journal all of these learning experiences and state clear steps regarding how you plan to improve. A year from now, when you will look back on your agile journey, you will notice how far you've arrived without even noticing.

Leave a Reply

Your email address will not be published. Required fields are marked *