Overview

How to handle unfinished User Stories in Scrum

1 Comment

Have you heard of Berlin’s new airport? Landing of the first plane was originally expected for 2007, then for 2010, later it was 2011, 2012, 2013,… – and making a long story short: the grand opening party for 2017 was just postponed for an undefined time.

Whether we talk about building airports or about building software, people tend to underestimate the amount of unfinished work. Well, even if they don’t, most people tend to give a more boss- or customer-friendly answer: “I’m 95% done” just sounds better than “I’m in the middle of this complex thing, and yes, I underestimated it, and to be honest, I don’t know what other unforeseen problems will occur on my way to the solution.”

empty airport

Although this nearly-done-status sounds good; it’s a killer for transparency on the project status. That’s why in agile development – for example with the Scrum process – you only care about entirely completed features. It’s binary. In the Scrum demo meeting you look at each User Story, check it against all acceptance criteria and the team’s definition of done (DoD). Only if all the work is done, all NFRs and other parts of the DoD are satisfied, only then the User Story is resolved and closed.

In agile software development the status of a feature is binary. Done or not done – Nothing in between.

It’s okay to slice User Stories, for example by workflow steps, business rules or by data variation to make them fitting into a sprint; but the defined scope and quality needs to be finished completely. Do not let a development team go away with resolving User Story A because it’s nearly done and at the same time adding a new Story “Finishing last bits of User Story A” to the backlog.

Saying that means we need to define how to handle unfinished features. I worked with many teams where this question was discussed extensively and emotional. If you work with Story Points the development teams often feel treated unfairly, if they finished “95% percent” (see above) of the work, but don’t get any credits for it. These discussions are getting even more emotional in environments where the management misunderstands Scrum and the concept of Story Points and judges Scrum Teams by their velocity.

So again, how to handle unfinished User Stories in Scrum?

My first answer is: You should not care too much about this question. It should be an exceptional case that the team did not finish a User Story. So, no matter what solution you choose, it shouldn’t have a significant impact on any of your metrics. If this is not true for your team, you have another problem you should solve; instead of fighting symptoms by giving your team credit for half-baked implementations.

Don’t care too much about an exceptional case!

The second part of my answer is: Unfinished stories should not be part of the demo meeting. They are moved to the top of the Product Backlog, instead of going automatically to next Sprint’s Backlog. So no Story Points are marked done for an unfinished story. Before the next planning meeting the PO (after consultating the developers) decides if he/she wants to spend more time on this User Story. If the answer is “yes”, during next planning meeting the User Story is moved to the Sprint Backlog with the same estimation as it had originally. Even if developers pretend that the feature is 90% done – all Story Points go to the velocity of this new Sprint. As I said before, unfinished stories should be exceptional, therefore in the long term team’s velocity will average out smoothly. Even though I hope that you’ll finish your projects faster than these guys from the BER.

See also:

https://www.mountaingoatsoftware.com/blog/dont-take-partial-credit-for-semi-finished-stories

Kommentare

  • Thomas Jaspers

    I like this view on the topic and share it. Funny thing is that of course the velocity will also average out if this is happening more often, but obviously this indicates some problem then.

Comment

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