Switching user stories mid sprint

On the Scrum Development, forum one of the members asked a really valid question. The scenario he presents is as follows:

The Sprint is two days old. The PO comes to the daily standup meeting and advises the team that the one particular story is no longer needed and he wants to switch the user story with one of equal weight. He wants to know what he should do.

My opinion on this is of course - it depends!

1. The team may have already started working on the story. So throwing the no longer needed story out means that the team has lost time already invested. So in this scenario, I would wait till all the other stories are done before considering switching in another story of equal size.

2. The team may already be behind. Since the team is two days in, they may already have uncovered unexpected complexities in what they're doing. So if there is already stress from a velocity perspective I would again wait till the other stories are done before agreeing to switch the new story in.

3. The Story is not properly defined and it starts eating in to development time to work with the PO to elaborate and define acceptance test criteria.

If neither of the above is true then, I'd feel comfortable letting the PO know that the team agrees to switch stories

I will however suggest that the Team decides. The PO can't override in this scenario unless he agrees to abort the sprint.

I would love to hear your thoughts on this topic so please leave comments below! Thanks

Jack

Written by Jack Milunksy - COO at Brightspark, certified ScrumMaster and Co-founder of Agilebuddy (Agile project management software that lets you easily Create, Estimate, Plan and Track your software development projects). For great Agile tips follow Jack at: www.twitter.com/agilebuddy. To get more info on Agilebuddy please visit: www.agilebuddy.com

Comments

[Darby Felton]

I think you've run into a very typical problem that Scrum is specifically designed to address - of ever-changing requirements. That said, it is important to keep in mind that strict adherence to any rule set, including those of Scrum, without regard to the customer's most important needs, can be detrimental to the project. Ultimately, you're right - it depends on the situation.

First, a minor clarification: I think you mean to say "The Sprint is two days old," rather than, "The Scrum is two days old."

Scrum provides that during Sprint Planning, the team commits to a set of User Stories that comprise the Sprint Goal. For a successful Sprint, it is of utmost importance that the Sprint Goal not be changed in spirit. That is, if by changing the User Stories, the Sprint Goal has changed, then you have not created the environment for a successful Sprint. The main idea is that the team is set loose for the duration of the Sprint on a fixed Sprint Goal. It is possible, however, that changing a User Story does not ultimately affect the Sprint Goal, but I'd be wary of changing targets during the Sprint. It is exactly this that the guidelines of Scrum prevent.

That the User Story that is to be replaced with another of equal importance is troubling for at least three reasons:

(1) it could effect a change in the Sprint Goal, which diminishes the value of the Sprint per se in terms of having a fixed target for the Team and insulating them from changing requirements for the short Sprint duration,

(2) if the User Story that is to be replaced is of equal importance to a new User Story, then the new User Story can probably wait until a subsequent Sprint to be addressed, and

(3) it implies that inadequate Sprint Planning has occurred, and perhaps the Sprint should not have begun until a fixed Sprint Goal can have been achieved. Because a Sprint is of relatively short duration, it should be possible to adequately plan a fixed target for a Sprint. Changes to User Stories and new User Stories should be addressed in later Sprints in accordance with their priorities.

Whether or not to allow the change should be considered in terms of whether it changes the Sprint Goal to which the team has committed. If it does adversely affect the Sprint Goal, then the Team can either: (1) choose to disallow the change, and address it in the next Sprint, provided that the Product Owner would accept this, or (2) choose to cancel the Sprint altogether. If the team chooses to cancel the Sprint, which should be the option of last resort, it is of utmost importance that the responsible person(s) be held accountable. That is, why was the Sprint canceled?

No one is allowed to change the Team's Sprint commitment during a Sprint - that is one of the basic tenets of the Sprint. Only the team can decide what changes to allow during the Sprint, and they should only allow the changes if the Sprint Goal remains constant and they believe that they can meet the additional commitment that the changes will require. The depth to which the Sprint Goal is achieved is ultimately up to the team.

Management, such as the Product Owner, can cancel the Sprint, but the cost of the canceled Sprint and the required adjustments (e.g., additional Sprint Planning) should fall on the responsible person(s). Because of the short Sprint duration, early Sprint termination should rarely be undertaken.

[Jack Milunsky]

Hi Darby,

Thanks for pointing out the error. I fixed that. Thanks also for your comments. I don't think anything that you say I could really argue with. My feeling however is not to take such a hard line.

I think the issue is not whether you're swapping a story of equal importance, you're swapping a story of equal size. i.e. during the sprint the PO feels that a new story is more important e.g. a sale may be dependent on that story for example and this just happened.

My opinion is that the team decides whether or not they can accomodate, assuming as I said above that they hadn't already started the story. And perhaps they could leave this one till last.

Jack

[Jonathan Whitaker]

Hi Jack

I've read your initial post and Darby's response with interest and both of you make very valid points.

Looking at this with a pragmatic mind, regardless of why a story is in the current sprint backlog but is no longer required, it doesn't make sense to be pedantic about removing it if the sprint goal isn't compromised to the extent it would be better to start afresh.

It should be noted though that removing a story will incur a velocity cost as the team will need to conduct an impact analysis on the remaining stories and sprint goal and potentially undo any work already done. The cost impact risk gets worse the further into the sprint the team is. Of more cost though is then having to revisit the sprint planning session to incorporate a replacement story.
This mid-sprint 'context switching' cost means that any substitute story cannot be the same size as the one being removed (and the factor may be as high as 1.5 to 2 times).

As you say, the purest approach to allow a story substition would be for the team to work through the committed sprint backlog (excluding the removed story) and if they meet their commitments then take a new story off the product backlog after consultation with the product owner in time honoured fashion. This approach may be more amenable than terminating the sprint and starting afresh - the team can make the call using their common sense though.

Regards

Jonathan

[Jacob Karma]

Something similar has happened to me during the current sprint (which ends in two days). The simple solution, if you have a decent team, is to remove the deprecated story. Then, if your team is a bunch of slackers they will just carry on at a leisurely pace. If they're a good team, they will come to the PO and say that there's nothing to do. This is when you can provide a list of replacement stories, sit down with them, and let them pick one.

Just how I'd do it..

[Chuck van der Linden]

"No one is allowed to change the Team's Sprint commitment during a Sprint - that is one of the basic tenets of the Sprint. " This has to be balanced against how much value you place on adhereing to a plan, especially when it has come to light that the plan is now wrong.

That policy exists I think mostly because we are trying to prevent randomization of the team. I think the PRIMARY goal is to prevent ADDING work. Preventing the team from doing work that will not be used otoh should always trump adhearing to the sprint plan. (that being said, it doesn't mean you get to slip something else into the sprint 'for free'

The scenario as presented also seems to assume there is no interdependencies between stories, removing one story could have impacts reacing far beyond the one story, so just because you are pulling say a 16 point story, doesn't mean there is now that much excess capacity in the sprint.

IMHO there is also a slippery slope here you want to avoid, which is the notion of playing story substitution (for ANY reason), because once you've done it once, how far is it from 'we don't need this at all' to 'we won't need this this year/quarter/month/sprint' and where does that stop.

Obviously 'why' this happened should be reviewed at post mortem. But we should realise as we consider how to respond that it may not represent failure at any level, and our response should not presume this is someone's 'fault' and be hostlile or vindictive. The need for this change could simply be a represent or change in the world around us, market conditions, rules and regulations, or perhaps someone found a workaround or other way to meet the business value that the story was to provide.

I'd say
1) Pull the not-needed story.. But that's only if it's not needed EVER or a pretty darned long time. And have the team assess the overall impact of that on the rest of the work in the sprint. Don't pull it if it's a case of someone changing their mind and saying it can be done next sprint, etc. it really should be no longer needed for the forseeable future.
2) Unless there are other external dependencies that make it awkward, simply let the sprint end early. Have the team re-scope and pick a new end date I vastly prefer that to the notion that killing one item gives you the right to a free substitution.
3) IF there's a good reason to have the sprint end remain fixed, then have the team estimate their excess capacity, pull the first item off the backlog of appropriate size, and stick it at the FAR END of the stack of work for the sprint.

[Paul Jackson]

Some great shared stories and comments here. This just goes to reinforce that Scrum is all about common sense. On one hand the Sprint is short so why can't the PO wait and add the new Feature to the next Sprint? On the other hand, the PO should have a deep understanding of the business value of each feature, and if the new one is critical, perhaps this should be included, or at least result in an exceptional temination of the current Sprint. The comments above are pleasingly pragmatic, which reflects Scrum in the real world - we've all faced these problems! I had a similar problem which I wrote about in a blog article: The Sprint Burndown Chart - Every Picture Tells a Story: http://blogs.sixninjas.com/paul15/?p=86

[Project Management]

Great post and comments to follow. Will bookmark and track back. Thanx

[Chuck van der Linden]

We've been discussing this over in the linked-in Scrum Practitioners group (http://www.linkedin.com/newsArticle?viewDiscussion=&articleID=52147072&gid=52030) and some great comments by John Clifford have me changing my mind as to my answer.

Abandon the sprint and re-plan. do a retrospective and be sure to discuss why the change came about, then replan the sprint.

All the answers as to how much work has been done, how the change impacts other features, the status of all the 'it depends' conditions that jack made reference to, will all have to come out and be discussed in order to decide what to do, and the proper venue for all of that is the process of replanning the sprint. If the change is truely simple, then you'll be done quickly and can restart work, perhaps with a new work item or two in the sprint to make up for the things that were completed or removed. If the changes have greater impact it will take more time, but you won't discover and properly cope with that impact without replanning.

[Jack Milunsky]

Hi Chuck,

Thanks for this input. I personally still say it depends. I think there are situations where there will be impact with a change like this and in that scenario the team have full right to terminate the sprint. But in the event that it really is just a switch of stories with no obvious impact, I say go for it.

Cosider this. If under normal circumstances, the team finishes early, they can then say to the PO give me more. In a way that's also changing the plan. But it's still the team in control.

I prefer not to terminate a sprint if at all possible ... it seems harsh given my understanding of the original request.

[Jack Milunsky]

@paul. Thanks for your input. I have to agree that especially in cases where Sprints are short, like 1 week then it's a no brainer to say wait till the next sprint.

If it's a month sprint, then I'd say it depends based on my previous arguments above. No matter what the Team has control over this decision. If they say No then this results in a termination of sprint.

Jack

[ilan berci]

It's amazing that a simple system constructed to address the deficiencies in software development by a straight forward approach has slowly evolved over the years to become more complicated than the system it was trying to simplify.

I like scrum and think it's a great asset in software development but situations as the one you describe will take some one with knowledge of the situation and the factors involved to make an EDUCATED EXECUTIVE DECISION. There is simply no rule you are going to pull out of a book... you are not a robot.. please, please, keep some fluidity and intelligence within Scrum (as was intended). Stop wasting time fine tuning scrum and get the f@#$king work done already!

ilan "give me results instead of problems" berci

[lonnie.haire]

interesting... i do appreciate ilan's input. i've read trust issues plenty and situational solutions. when the decision tree starts iterate on itself or flatten out, it may be time to consider a different way. 'if-this-then-that', what about cost or laziness, the team should, the po shouldn't... goodness, how do we move forward with all this conflict and indecision?

there are plenty of valid points to consider if the assumption is "just enough commitment" negotiated on day 0 of the sprint. what if you could commit a known or suspected stretch item into each sprint? this solves a lot of the problems raised without breaking any rules, in so much as both the team and the po identify the stretch item and understand what should be expected (a new rule).

anyway, just a new thought or a simpler alternative to some of those mentioned above.

~lonnie.haire

[Jack Milunsky]

Ilan, while I appreciate your opinion on this topic, the bottom line is folks face situations and want to know how to deal with them. This is not a question I thumb sucked. My blog is to educate, to discuss topics that arise from time to time on the forums and to debate interesting topics. It's not about complicating anything. And I agree with you teams neet to make educated or executive decisions but if you're an immature Agile team then this question is very valid.

Thanks for your comments.

Jack

[Mark Levison]

Once maybe - but remember the purpose of a sprint/iteration is to give the team an island of stability. If it happens more than once then the PO is having trouble keeping their priorities straight. In the second case I would say no and bring it up in the retrospective. If the requirements really are unstable then maybe the iterations are too long.

[Jack Milunsky]

Hi Mark,

100% agreed. Teams need to keep sprint's as stable as possible. Otherwise no work get's done and it all just falls apart.

Jack

[Bruce Onder]

I don't see the harm if:

a) the story to be dropped is further down the prioritized backlog than the team has gotten to so far in the sprint;

b) the new story goes in its place, and

c) the team agrees that the new story is the same size as the one it's replacing.

If those three things are not true, then there needs to be a larger discussion around risk to the sprint if the change is made.

--Bruce

[Jack Milunsky]

That's why in my original blog I say it depends. And I agree it does depend on those 3 things. Never the less there should be a sense of stability during a Sprint and so this shouldn't be something that continuously occurs. If it does, I would start off by shortening the sprints.

[metro ethernet]

is such a pleasure for me to participate in blogs like this, are so educative, and so useful
thanks a lot
xoxo