When your scrum team has finished the sprint's work early, what are the official rules/guidelines for accepting more work? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

This question does not appear to be about programming within the scope defined in the help center.

Closed 5 years 开发者_Go百科ago.

Improve this question

Specifically, should you only accept new work you know the team can finish in the given iteration? Is it ok to start the next highest priority backlog item even if you know the team doesn't have time to finish it? Thanks!

---

We use the time to fix bugs, and to pay back some technical debt.

If you can do this without talking to your product owner depends on your understanding of scrum or your work arrangement with the product owner.

In my personal opinion you make a promise for the sprint. Your part of the deal is to hold the promise. The Product Owner on the other hand is supposed to stay out of technical stuff, since that's what the developers are good at. Technical Debt is technical stuff. Bugs might be. But in the end you have to come to a common understanding with the PO what you can decide on your own and what you have to consult the PO with. In an ideal world the developers know so much about the product that they can make the decision on their own.

Starting on the next item is of course another option. If you can't finish it, Lex Scrum says don't touch it. And I like this law to some extend, because it actually creates slack that can be put to good use by developers ... like fixing bugs and paying back technical debt. If implementing another story is the best use of your time: find one that you can finish. If you can't find/create one, this is actually an impediment that you just found. Assuming we are talking at least about something like 4hours for 2-3 developers, we really should be able to find something useful to implement with these resources, shouldn't we?

---

should you only accept new work you know the team can finish in the given iteration? Is it ok to start the next highest priority backlog item even if you know the team doesn't have time to finish it?

Remember "Individuals and interactions over processes and tools" Do what your common sense tells you. Do not get too caught up in tools and processes.

As per the Scrum guide, the amount of work the Team commits to is completely up to the Team.

There is no harm in starting a next highest priority item when all the items above it are done. What would be preferable though is break the item down into a smaller or thinner slice which can actually be done.

If the Team finishes all it's Backlog Items well ahead of time, the team should definitely take up a few more.

---

I would take the next highest item in the backlog and work with the product owner on creating a story that can can be completed in this iteration...so break the story into a smaller size to fit.

---

We haven't taken new work irrespective of whether it can be finished within the sprint or not. You should instead focus on Technical Debt, Design Debt, Code Debt

---

Definitely break the story into something that fits. The team should never be committing to something it can't finish in a sprint. Additionally, only the team can add new work. If the team finishes early, the team needs to work with the Product Owner and agree to add work to the sprint. I've seen teams get into trouble when the "lead" or even the Scrummaster starts negotiating with the Product Owner outside of the team.

---

To answer the question definitively, Scrum says that you should negotiate with the Product Owner and about taking in extra work.

Scrum done well has the Scrum Team review their progress every day so you should see an early finish predicted way before it actually happens, giving you enough time to chat with the Product Owner about what to bring in to the Sprint.

Scrum done well also has the Scrum Team prepare User Stories well in advance of being pulled in to a Sprint (via Sprint Planning and Product Backlog Refinement) so the need to break a User Story into smaller components so they can fit in to a Sprint is lessened considerably.

---

Either you can break a story into a smaller one so you can deal with it within the current sprint or you can have a story informally split into two sprints putting off some of its tasks to the next one.

Remember that agile comes down to finding the best way to fit your team's needs, not about following structured rules.

---

Whichever way you go, I'd simply go to the team and ask them what do they want or think they should do. Remember, in Scrum we value self managing teams. For suggestions, if they're stumped, I would say do one of the following:

• Reduce technical debt
• Use the time to learn something valuable
• Let the team take a "Gold Card". They're on time, they probably earned it.
• Split the next story into smaller (though still meaningful) stories, the first of which can be completed in time for the end of the sprint.
• If the next story can't be completed as above, take the next story that can be completed in time.

Hope this helps,
Assaf.

---

Here's what my teams do-

First, it's up to the team to decide what additional work that they can fit into the remaining part of the sprint. It's critical that the whole team votes on this, not just the developers.

Second, if the team decides that they can handle X more points of work then they go to the PO and confirm the priority of the backlog items and find one or more stories that sum up to that X points. Sometimes they have to move down the backlog a bit to find ones that will fit. As long as the PO is ok with the final selection, the team moves forward with the new work.

Third, whatever new work the team selects has the same commitment level as the original work. Any partially completed stories at the end of the sprint are failed.

Finally, during planning for the next sprint, the velocity is adjusted upward (in this case) because it's quite likely that the team under-selected work at the beginning. This is a crucial point - the velocity should always reflect the team's best guess based on recent past history as to their work capacity. If the PO sees that the team is finishing early and heading off to do other non-backlog work, this can cause trust problems between the PO and the team. It's perfectly fine to decide as a team along with the PO to focus on technical debt (although I think that these are still stories since the work needs to be tested) or other items as long as there is discussion and agreement.

---

I think this is something you'll need to take a view on after a number of sprints. If you're regularly left with spare time at the end of a sprint, you should probably commit to more work in the planning session.

If it is happening rarely, I'd caution against routinely adding in tasks from the backlog as a matter of course. Unless you've done some decent backlog grooming they're unlikely to be the quick-wins they first appear. You also want to avoid a protracted mini planning session as those days you have free could quickly trickle away - especially if you're including the views of developers who have tasks outstanding.

By all means, seek to get ahead for the next sprint by reducing technical debt or backlog grooming etc but putting yourself on the back foot by committing to work late on is rarely worth the effort.

---

I think a solution of an under-committed sprint could be to stop the sprint. If the team has done the work then the sprint is over. The other option of adding more stories into the sprint backlog is too risky, and rarely will a team be 100% sure they can handle all the extra work. As far as I know there is no rule that a (let's say, 2-week) sprint cannot be ended 2 or 3 days early.