Quino Al / Unsplash

The problem with unfinished User Stories

Just imagine: What a beautiful spring Sprint! The sun is shining, developers are developing, you are Scrum-mastering and Product Owners are rejoicing. Suddenly, you discover something very unpleasant: not all User Stories got marked as ‘Done’ at the end of the Sprint. How did that happen?

How did we get ourselves into this mess?

We’re not dealing with absolutes here. Yes, we evaluate User Stories as best as we can so that Product Owners are able to assess how much work will be done during the Sprint. This also gives them a chance to plan their future development strategy. But it is very hard to evaluate User Stories perfectly because you simply can’t predict the future. Let’s be honest, sometimes you miss an important aspect of a User Story and it consumes more time than expected. There are plenty reasons why this happens. Some you can try to eliminate. Others are there just lurking in the shadows waiting to surprise you.

Forgive me for I have Scrummed

You probably figured out by now that this situation isn’t optimal. The work isn’t finished, the Sprint is coming to an end and your Sprint Goal might be in jeopardy.
Another element you’ll have to deal with is the imminent effect it has on the development team. It’s demotivating! Especially when they feel committed to deliver what they have promised within the Sprint.
And of course, Product Owners will struggle with this situation, too. They feel responsible—in this case, to the stakeholders. In the words of our SQA Leader Jakub Kmínek on the impact of this on the Product Owners:
“It’s like meeting with an old friend for a cup of coffee. If you come late once, he’s willing to forgive you. If you come late all the time, there’s a big chance he won’t be waiting for you anymore.”
The stakeholders are losing trust in the product team and their ability to deliver. Occasional mishaps can be tolerated, but each falter decreases trust a little bit, and trust is very hard to rebuild. You may even hear something from the team like, “It’s not working; we’re not delivering. We told you our [enter previous style of work] was better!” Unfortunately, you know this is not true. You still remember how things were done before starting to use Scrum. You take a deep breath and try to think. Can we prevent these betrayals in trust somehow?

What goes down must come up

Well, there’s no easy answer to this. From experience, I can say that these things will happen, and I acknowledge that this might seem a bit depressing. But there is a first step you can take: do your best to avoid this kind of situation by following the Scrum MF rules. And if a User Story can’t be finished despite your best efforts, learn from your mistakes. Do a root cause analysis and make an action plan to prevent the problem in the first place. This refinement is a process every team must go through. You’ll see improvement over time.

The deed is (not) done. What now?

There are a few ways to handle the unfinished items. These questions will help you decide what to do:
  1. Is the item still relevant?
    An unfinished item needs to go back into the Product Backlog so that the Product Owner can reevaluate its priority. Many of these items end up right back at the top of the Backlog and you’ll continue to work on them. But priorities can change, and sometimes a partially done User Story can get scrapped. That’s why this verification of relevance is needed.
  2. Split it or move it to the next Sprint?
    Some suggest splitting User Stories, leaving what’s completed in the last Sprint and moving the unfinished business to a new one. I’m not a big fan of this approach. It ignores a basic rule that a User Story is only done when it’s completely done. I keep it simple: I move the User Story to the next Sprint and keep working on it. No splitting of points, no rewriting of descriptions, no ignoring unfinished business.
  3. What about velocity?
    You may feel that splitting User Stories will give you a more precise velocity reading. In my view, it is not worth it. Velocity is by its nature imprecise. If you move all unfinished items directly to the next sprint, you might feel like you’re robbing your developers of the already-finished partial effort. But that is not really the case; they’ll just have to wait for recognition for a bit longer. Remember, this is not rocket science. Velocity is just there to serve you as an indicator.

 

User Stories always form the basis of product planning, and while it’s ideal to fully complete all of them in each Sprint, that’s not always possible. Not finishing an important aspect of a User Story in a specific Sprint is a common problem, and while that reality can affect trust within the team, by using our tips above, it might be a little bit easier to stomach.


Remember, when all is said and done—don’t forget and keep it Scrum!

You may also like:

AMI Interview with Marina Pantcheva

In this episode of AMI Interview, we sat down with group manager Marina Pantcheva to talk about her history with the company. We discussed…

AMI Interview with Robert Silar

In this episode of the AMI Interview, we spoke with our Development Manager, Robert Silar, about how AMI was created and our plans for…

AMI Interview with Andrea Hendy

In this episode of the AMI Interview, we spoke with our Scrum Master Andrea Hendy about the differences between Scrum Masters and Agile coaches,…