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.