Can I swap stories?

Question

There's a story we committed to in the Sprint. After the developer looked into the ticket, it needed feedback from client. A week has passed and still no answer The developer completed other tickets in the sprint and moved on to pick up a ticket in the backlog. Should we leave the tickets where they are or swap them? We won't be able to complete the new ticket from the backlog before the end of the sprint.

Answer 1

In Scrum, you do not commit to scope of work. Instead, the Developers commit to the Sprint Goal at the Sprint Planning event. This gives the Developers flexibility in the work that they do to achieve the goal, which allows for adaptability in the course of the Sprint as the team learns more or unexpected things happen.

If the work represented by the story (or, in Scrum terms, the Product Backlog Item) is required to achieve the Sprint Goal, the lack of feedback from the client should have been addressed before a week passing. The Developer should be involving both the Scrum Master (as someone who can help remove impediments) and the Product Owner (as the person accountable for maximizing the value of the work done by the Scrum Team) to understand what is happening and ensure that the most possible value is being delivered.

If the Sprint Goal is in jeopardy because of the work not able to be completed, the Product Owner definitely needs to be involved. As the voice of the stakeholders, the Product Owner can make decisions on the best course of action to take.

If the Sprint Goal is not in jeopardy, then there's nothing preventing the Developer from taking new work from the Product Backlog. However, it wouldn't be my first choice. If the Developer came to me and asked me what they should do, my first recommendation would be to see if there was a way to help with work directly associated with the Sprint Goal. If the Sprint Goal was met or no help was needed, move on to other work in the Sprint Backlog. I'd even suggest working on refinement activities or work to improve the team's way of working before pulling something new from the Product Backlog, especially if it won't get to Done before the end of the Sprint.

Answer 2

TL;DR

While good user stories are negotiable, and user stories of the same size are theoretically fungible from a capacity planning standpoint, stories selected from the Product Backlog for Sprint Planning should be tied to the Sprint Goal. You may or may not be able to meet the Sprint Goal without this user story; that's something the Scrum Team must collectively discuss.

Analysis and Recommendations

The Scrum Team must answer three key questions to determine the correct answer for your situation:

1. Is this user story an item from the Product Backlog accepted into Sprint Planning, or just an item that the Developers created on the Sprint Backlog to meet the Sprint Goal?

   The Product Backlog belongs to the Product Owner, and describes what should be built. The Sprint Backlog belongs to the Developers, and describes how they will meet the Sprint Goal. The Developers are free to add, swap, or drop stories or other work items from the Sprint Backlog as they see fit, provided it doesn't impact the Sprint Goal.

2. Is completing this story essential to meeting your current Sprint Goal?

   If not, you can swap it, drop it, or use it as fodder for the Sprint Retrospective to determine why you have Product Backlog items in your Sprint that aren't related to your Sprint Goal.

3. If it's essential to the Sprint Goal, can you negotiate the Sprint Goal or the scope with the Product Owner?

   In Scrum, scope is the adjustable constraint. Good user stories are also intrinsically negotiable. If you have a story that's essential to the Sprint Goal, the scope of the Sprint Goal can be negotiated with the Product Owner. Alternatively, if not completing the story would invalidate the Sprint Goal or endanger the Product Goal, the Product Owner can call for an early termination of the Sprint and a return to Sprint Planning.

The goal of a Sprint isn't to complete every user story; the goal of a Sprint is to complete the Sprint Goal! So, that's where you need to focus the team's attention, and the answer to how the story impacts the Sprint Goal (if it actually does) will either constrain or free your options on how to handle this particular user story.

Answer 3

Rather than looking at what we need to do in this kind of situation, we must focus on what we must not do to come into this position. Let's analyze the problems in your case;

1. "After the developer looked into the ticket...": Why did the developer look into the ticket in the sprint? All the developers should be looking at all tickets in the backlog before taking them into the sprints.
2. "... it needed feedback from client": If a ticket needs feedback from the client, why is it in a sprint? A ticket/issue/task/story must be groomed while it sits on the product backlog. When the team agrees that there are no gaps in the issue and the assignee can complete it without any input, the team takes it into the available sprint.
3. "... moved on to pick up a ticket in the backlog": This is against the nature of the sprint. Every sprint should have a predefined goal and a set of stories to work on. When one developer adds another story into the sprint, how will the designers, testers, and even the product owner manage their workload? If you are after productivity, I have an article titled "What Happens When Your Sprint Backlog Is Out Of Items?". You can check it out.
4. "... or swap them?": By running sprints, you are saying that "We are going to do these in these X weeks". If you take a story out, the stakeholders will ask the team where that story is on your sprint review meeting. The rule is simple; do not take stories into the sprint or take stories out of the sprint.
5. "We won't be able to complete the new ticket from the backlog before the end of the sprint.": Absolutely. If you could, you would already take it into the current sprint.

So, while these anomalies exist in your sprint, taking what you think the best action is won't change your situation dramatically.

Answer 4

Lots of great comments here, and I'll risk being yelled at for dumbing it down. Yes, if you're meeting your sprint goal it shouldn't matter. And yes, in your situation where you should have had information that you didn't, it probably wasn't best to put it in your sprint.

But, stuff happens. You want to minimize stuff happening because you want to be able to have a happy team that doesn't feel like they're being thrown in different directions, but can confidently move towards and complete their goals.

In the real world, that's not always the case when boss A suddenly want this thing done tomorrow and doesn't care about your garsh darn scrum methodology. And yes, from time to time you may have to "swap" tickets. Just avoid it when you can. It's better, at least, than straight up scope creep, where you just start adding points.

Some software even has metrics for this. Scrumfast for instance shows both Scope Creep and points swapped. The idea, of course, to minimize both.

Good luck!