7

Suppose a task shows up mid sprint that is high priority. It must go into the current sprint and take top priority.

Suppose the task is estimated by the development team to be a 3 point task.

When adding this task to the current sprint should an equal number of points worth of tasks be removed from the sprint or do you only add tasks?

Improve this question
1
  • None of what you're describing is Scrum. What's your Sprint Goal? Why is anyone outside the team creating tasks? If it's a story that upends the current Sprint Goal, why are you not terminating the Sprint and going back to Sprint Planning? Where is the Product Owner in all this? The whole scenario you're describing just seems inherently anti-Scrum, and the question about story points seems like an X/Y problem.
    – Todd A. Jacobs ♦
    Feb 22, 2017 at 5:09

5 Answers 5

Reset to default
8

Let the team decide.

Just because both stories are 3 points that does not mean that the disruption and context switch is not bigger. The Development Team should desire if they are taking the story, and what the impact is on the Sprint Goal.

Improve this answer
5
  • That was our conclusion but we have two teams and we are somewhat debating on what the "right" way to handle the situation is. It's ok for us to do both ways for different teams but I was just wondering if there was an outside impartial opinion on which way to lean.
    – justin.m.chase
    Feb 21, 2017 at 2:19
  • by "taking the store" you mean "taking the story"?
    – justin.m.chase
    Feb 21, 2017 at 2:21
  • Yes, Story: And you should always, let the team decide. The Product Owner sets and communicates Strategic Direction and the team decided how best to fulfil that.
    – MrHinsh - Martin Hinshelwood
    Feb 21, 2017 at 12:33
  • +1 to @MrHinsh. Regarding two teams considering different tactics, it's important that both understand the rules of Scrum when they make their choices. Scrum is guidance distilled and matured for than 20 years. That would make a heckuva single malt Scotch! Once they are well equipped in this knowledge, they may well see that it's not necessary that both teams agree on a "right" way to work within the Scrum framework. They will be called to respect each other's team as self-organizing, and allow for variation in practice.
    – jason.t.knight
    Feb 28, 2017 at 14:20
  • I marked this as the answer because its the one I liked best not because its the correct answer :D which is just my opinion.
    – justin.m.chase
    Mar 2, 2017 at 0:42
11

Typically, yes.

The amount of estimated work in the Sprint represents what the Development Team believes it can accomplish during that Sprint.

If new work comes up, it's not like the Team suddenly becomes able to accomplish more work. So if you are adding work in, take work out.

Unless, of course, for whatever reason the Team decides it does suddenly have the ability to complete more work than it thought it would at the beginning of the Sprint.

Note that another option, if the new work is so invasive that it puts the likelihood of accomplishing Sprint Goal in question, then you should consider cancelling the Sprint and starting a new one, traumatic though that may be.

Improve this answer
3
  • 1
    Part of the problem with adding tasks to the sprint is the cost of context switching. If you are pulling tasks out for equal points, how do you measure the cost of context switching?
    – justin.m.chase
    Feb 21, 2017 at 2:59
  • @justin.m.chase There's no rule that you must push out the exact same amount of work as you pull in. The Team decides how much work they think they can accomplish; this includes loss due to context switching. All this does is increase the difficulty of estimation - the actual process and goal remain unchanged.
    – Sarov
    Feb 21, 2017 at 5:42
  • @justin.m.chase two quotes form the Scrum guide apply here: "Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances," and "Inspections are most beneficial when diligently performed by skilled inspectors at the point of work." If after inspection it becomes clear the work may be added without threatening the Sprint goal, the Development team is the group most equipped to make that adaptation. There is more guidance from the Scrum guide in my answer below.
    – jason.t.knight
    Feb 28, 2017 at 14:15
4

TL;DR

  • The Development team has complete control of the Sprint Backlog during a Sprint and may well swap out the work as you have suggested.
  • The Development team may not be bullied or coerced into taking the high priority work into the Sprint under any circumstances.
  • The Development team should try very hard to accomplish the current Sprint Goal and any work order highly by the Product Owner
  • The Product Owner has the final say about what work is accomplished in what order in the Product Backlog
  • Scrum provides rules that prevent wasteful context switching and visionless changes mid-Sprint. It ultimately calls for the PO and Development team to act with respect, openness, commitment, focus and courage towards one another when forming a solution to your proposed situation.

This is ultimately a Development Team decision but it involves potentially everyone on the Scrum team. The Scrum guide specifies several rules to consider here:

No one [other than the Product Owner] is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says.

The Product Owner is the sole person responsible for...ordering the items in the Product Backlog to best achieve goals and missions...

For the Product Owner to succeed, the entire organization must respect his or her decisions.

The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog.

If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.

As new work is required, the Development Team adds it to the Sprint Backlog.

Only the Development Team can change its Sprint Backlog during a Sprint.

During the Sprint: No changes are made that would endanger the Sprint Goal.

Great flexibility exists to incorporate new work within a Sprint so long as the Sprint goal is not threatened. Ultimately, this is the choice of the Development Team as they own the Sprint Backlog and may not be told to work on things the Product Owner has not ordered as work to be taken next.

Should a Product Owner deem it necessary to for the Development team to work a high priority task this may certainly be incorporated into the current Sprint but only by the Development team and only with full knowledge of the request. If the Sprint goal is threatened by such work, the Development team has the obligation to push back respectfully. They are also obliged to do whatever they can to negotiate regarding the Product Backlog Items in the Sprint so long as they still accomplish the Sprint goal even while incorporating the new work; however, the Sprint goal must not be sacrificed.

Ultimately, it's the Development team that must provide the answer to your question as Scrum does not prescribe any answer; however, Scrum establishes the Development team as a self-organizing group of professionals which must be trusted to have as their highest aim to delight the Product Owner. Likewise, Scrum defines the Product Owner as being the final arbiter of the order of work completed who's ultimate aim is to maximize the value in the Product and of the Development team's work. The answer requires that mutually respectful and at times courageous conversations take place between the PO and Development team with the Scrum Master facilitating this conversation as needed.

Improve this answer
0

The short answer is no.

As there is not too much information on the background of the request and your team, I will simply come up with some if statements for a couple of cases.

Has it been long since the sprint has started?

  • Yes: You are close to the end of the sprint, so it will be better to include the new story in next sprint.
  • No: You can abort your ongoing sprint, have proper sprint planning session including the next story at the top of the backlog.

Is this an issue or a story?

  • Issue: It's best to allocate a buffer to address issues (especially production ones) while planning the sprint. With such a slack, you should be able to include a 3 point issue in the sprint without risking sprint goal.
  • Story: The client should wait for next sprint. If it is an extremely important change/feature that is really really urgent, then it should be ok for you to abort the sprint and focus on this as the team.

Lastly, if the team approves the addition of the story into the sprint (considering its small size), then you should not make any other changes like removing another one. At the end of the sprint, the story with the least priority in the sprint may be incomplete, and that would be the topic to discuss in the sprint review.

Improve this answer
0

In this case the priority of the backlog is important. Capacity and time are fixed. If you add unplanned story (something which should be done only in exceptional cases) you should remove low priority story.

Story size and estimation should be discussed with the team.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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