Agile – Scrum – how to carry over a partially complete User Story to the next Sprint without skewing the backlog

agileestimationplanningscrum

We're using Scrum and occasionally find that we can't quite finish a User Story in the sprint in which it was planned. In true Scrum style, we ship the software anyway and consider including the User Story in the next sprint during the next Sprint Planning session. Given that the User Story we are carrying over is partially complete, how do we estimate for it correctly in the next Sprint Planning session? We have considered:

a) Adjusting the number of Story Points down to reflect just the work which remains to complete the User Story. Unfortunately this will mess up reporting the Product Backlog.

b) Close the partially-completed User Story and raise a new one to implement the remainder of that feature, which will have fewer Story Points. This will affect our ability to retrospectively see what we didn't complete in that sprint and seems a bit time consuming.

c) Not bother with either a or b and continue to guess during Sprint Planning saying things like "Well that User Story may be X story points, but I know it's 95% finished so I'm sure we can fit it in."

Best Answer

In my current team we do c).

The velocity should account for things the team really finished in the sprint. Something that was not delivered has no value for the customer, so we don't count any points for it, it's all or nothing.

So we shift the whole unfinished story on to the next sprint and all its story points will be added to the next sprint's velocity. Velocities even out over time and we take an average of the few previous sprints as a reference to determine estimate future velocities.

Related Solutions

How does a Scrum team account for infrastructure tasks in the planning meeting

They're not actually user stories. They're stakeholder stories. Unless the software is actually paid for direct by users, it's rare that a story is created entirely for their benefit.

I give you a couple of examples:

keyworded articles, which allow advertisers to have more effective adverts
CAPTCHAs, which are there to stop moderators having to deal with spam manually.

Most technical stories actually provide a business benefit, but it's rarely for the users. Phrasing them in a different way can help. I normally use Chris Matts' Feature Injection template:

In order to <achieve my goal>
As <the stakeholder who wants the goal>
I want (<some users to do>) <some stuff>.

This explicitly recognises all kinds of stakeholders, including the development team. Now you can phrase your technical stories too, calling out the business benefit:

In order to minimize the risk of deploying something broken
As the team deploying the code
We want to spend a few days on an automated deployment system.

I've written a couple of blog posts on this: They're not User Stories, and Feature Injection and handling technical stories. Hope they help.

Agile – How to handle ‘external’ dependencies in scrum

Ultimately it depends on whether you are 100% confident that the external provider will deliver something you can use by the time you need to use it.

If you cannot be sure that they'll deliver in time then don't add the story to the sprint. However, just because they've always delivered in the past there's no guarantee they'll deliver this time.

You should let the customer know that this dependency exists and that you are going to have to wait for the API (or whatever) to become available before you can schedule the work.

On the plus side, there may be aspects of the story you can deliver - i.e. break it down further until you've isolated the dependencies as much as possible. This might allow you do some of the story before the supplier delivers their work.

One thing you could do is to create an interface between your code and the third party API. You code to your interface so the rest of the project can proceed and until you have the real API use a mock to return example data. Then when the real API arrives you just have to change the code behind the interface which won't affect the rest of the application. Only do this if you can agree with the the API's supplier that their interface won't change (at least not drastically).

Related Topic