6

The Sprint Planning is done and, in the middle of the Sprint, the priority changed. Because of the priority change, the story needs to move to a future Sprint.

This is not adding new stories, this is removing the planned stories.

The story is not yet started. Is this a good practice?

Two thoughts:

  1. Since the story is not started, it can be moved.
  2. The story is planned, estimated and tasks and hours were allocated. The story can be blocked and carried forward to future Sprints. This can help in finding the number of times stories are pushed.
2
  • 1
    Hi Sam, just a couple of (very very) minor things. Most teams are software development teams and 'push a story' is also shorthand for deploy/merge etc in Git. I would adjust the language slightly. To say 'we have not started a story so we are going to push it' made me smile. Also, a priority change is probably not a reason for listing a story as blocked. Unless I am missing some other context, your story is perfectly fine, it is just not going to be worked on right now. Aug 31 at 9:02
  • 2
    You can move it to the Product Backlog, but you can't move it to a "future sprint." There's a difference, and it's an important one.
    – Todd A. Jacobs
    Aug 31 at 13:44
9

TL:DR

Yes, it is perfectly fine to remove a story due to changing priorities and move it back into the Product Backlog, ready for a future sprint.

Why is it fine?

A Scrum Team can do several things as per the Scrum Guide

The Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail that they can inspect their progress in the Daily Scrum

and

The Sprint Goal is created during the Sprint Planning event and then added to the Sprint Backlog. As the Developers work during the Sprint, they keep the Sprint Goal in mind. If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.

and

Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint. The Scrum Team may refine these items during this process, which increases understanding and confidence.

A team can be both add to and remove items from the Sprint Backlog and also negotiate with the Product Owner to add to and remove items from the Product Backlog.

Other Considerations

Whilst the Scrum Guide gives you permission to do so, it is worth exploring with the team why the situation arose. Some sample questions you may be interested in include

  • Why did the priority change?
  • Where did the priority change come from? Was it driven by the team?
  • Was the story critical to the Sprint Goal?
  • Is the Sprint Goal still achievable?
  • Did the story have an engineering dependency that we missed?
  • Is the story still required?

A careful analysis of the events surrounding the removal of the story may yield interesting insights which help you improve the environment of the team

1
  • The concept of the sprint goal is probably the most important thing to consider. It is what permits you to move things to the backlog without creating anarchy. You're still going to reach a product that does what the PO wants it to do, and that's what matters (its up to the PO to make sure such juggling doesn't prevent the necessary progress)
    – Cort Ammon
    Aug 31 at 23:41
3

Within a sprint everything is supposed to be of equal priority. The scenario you describe therefore could mean one of two things. Firstly it could be that something not previously part of the sprint is now deemed more important, in which case you add the new item(s) to the sprint and that likely means you can't start something you originally planned to do. A second possible situation is that you don't add anything new, it's just that you no longer have capacity to do everything planned so you have to make a decision on what cannot be done. In either case, the PO should have the final say about what doesn't get done and whether new items are brought into the sprint.

In both those cases I would suggest leaving the de-prioritised story in scope for the current sprint and then at sprint review time reporting why it wasn't done. If you completed other backlog items instead then I would count those completed items towards the sprint velocity while of course not counting anything that wasn't done. I believe that would be the best way to honour the principles of transparency and accountability and would give stakeholders more confidence than if they saw things being removed mid-sprint. In particular, if the decision was due to capacity problems caused by work being underestimated or other blockers then those things are worth mentioning at the review.

At a future sprint planning session or during backlog refinement you can decide exactly when any left over items should get done.

6
  • "Within a sprint everything is supposed to be of equal priority." - Not if you have sprint goals.
    – nvoigt
    Aug 31 at 12:08
  • 1
    @nvoigt I guess what you mean is "not if you have something in the sprint that is unnecessary to achieve the sprint goal". But then I would be inclined to say the PO should have enlarged the sprint goal to include those additional things,
    – nvogel
    Aug 31 at 13:13
  • It's equal priority in that it has been agreed to be finished in the timebox. Obviously something has to be started first in the Sprint. Aug 31 at 13:33
  • 2
    @nvoigt Everything put into the sprint backlog during sprint planning should be achievable in the sprint, otherwise the team should not accept it into the sprint. The Scrum Guide says "No changes are made [i.e. during the sprint] that would endanger the Sprint Goal" and many people do interpret that as meaning sprint backlog=goal. However, I can see that the PO might want other things that are secondary to some priority goal in which case you are right. Good point.
    – nvogel
    Aug 31 at 15:13
  • 1
    @nvogel The Sprint Goal should be what the stakeholders "get" out of the sprint being done. The Sprint Backlog should be what the team thinks they need to do to accomplish the goal. If new information comes to light during the sprint about what is necessary to achieve the goal, the team shouldn't blindly keep working to the original sprint backlog (which is just "what we thought last week we would need to do to achieve the goal, before we had this information") they should update it. However such changes should be in the service of achieving the Sprint Goal. Change the plan, not the goal.
    – Ben
    Aug 31 at 22:55
0

If you can't delay the work (whether it's pushed to "a future sprint" or "moved to the backlog so it can be scheduled in a future sprint") then what are the options? Shutter the company?

If you can't work on something for some reason, the backlog is where it goes. This is even if the work has already been started. In that case, decide how much time the team will spend putting the work into suspended animation, and then backlog it. Assign the resources new work.

Regardless, later on the work should be re-groomed and started anew when the time is right. It's possible all previous work on the story will be lost.

1
  • 2
    As a small aside, the word grooming is not supported in Scrum any longer. That is an official stance. It has highly negative connotations in the UK and is unlikely to be tolerated in a corporate setting. Scrum realised the seriousness and removed the word, replacing it with refinement instead. You are free to keep using it but I thought I would let you.know. Aug 31 at 19:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.