I know that if PBI's cannot be completed within a sprint they can be re negotiated with the product owner

Now again a sprint cannot be shorted or lengthened then the agreed time box unless the sprint goal is obsolete. So how does the situation play out when the agreed definition of done is met before the time box expires?


5 Answers 5


Being a framework and not a strict process or method, Scrum does not dictate what should happen. The Product Owner and Development Team should work together to determine the best course of action. This is much like a situation where the it appears that completing the selected items is in danger.

There are several possible options in no particular order:

  • Add an additional Product Backlog Item that the Development Team believes it can complete before the end of the Sprint
    • Applies to Sprint Goal (or not)
    • Augments an existing feature (or not)
  • Use the time for Team activities
    • Celebrate achievements
    • Learning and training
    • Team building
  • Address any technical debt
  • Additional exploratory testing
  • Backlog refinement

NOTE: The Definition of "Done" applies to each Product Backlog Item forecast by the Development Team that has been added to the Sprint Backlog as well as the Increment as a whole.

The Scrum Guide


There are a few options. However, the Scrum Guide is silent on what to do.

First, the Development Team can begin work on the next item from the Product Backlog. Ideally, there are more items that have been fully refined in the backlog. The Product Owner should be ensuring that the Product Backlog is always in a good priority order and that the top items have been sufficiently refined to work in an upcoming Sprint.

Second, the Development Team can hone their skills. Use this as an opportunity for cross-training. This can also extend, to some extent, to the Scrum Master and Product Owner. Consider not only technical skills needed by each role to do their day-to-day job, but improving the understanding of the work done by the other roles on the team.

Third, pay down technical debt. Improve automated test coverage, improve manual test coverage (if you have manual testing), convert manual tests to automated tests, build tools to facilitate the development process, refactor parts of the application, gain expertise in other parts of the code that the team may not have been exposed to recently. Do things to make the next Sprint easier.

There may be other options, too, depending on your organization. Helping out other teams meet commitments, code reviews, additional testing.

In any case, the Development Team and Product Owner should work together to determine the best alternative. Perhaps the organization management can also look toward things that need to be done. This is also something that should be discussed at the Sprint Retrospective to determine how to better be more accurate in capacity planning in upcoming Sprints.

  • "Helping out other teams meet commitments" would definitely interfere with empiricism. If code reviews are not a part of the Definition of "Done" (and aren't covered by pair programming) then perhaps that should be addressed. Commented Nov 2, 2017 at 13:25
  • @AlanLarimer How does it interfere with empiricism? The fact that a team needed additional resources should still come up in a Sprint Retrospective and the team should get to the root causes (and associated solutions) that led to this state. It's also into the area of professionalism - if I have knowledge and skills that can help another team succeed without putting a burden on them, I'm going to. It's good for the organization as a whole to make commitments and deliver value to customers and users.
    – Thomas Owens
    Commented Nov 2, 2017 at 13:29
  • It affects empiricism of that second Scrum Team because both the outputs and outcomes of that Sprint have been affected. Whether the issue is the need for additional resources or training, or simply unknowns and complexities that arose during the course of work those can be inspected regardless. The professionalism of knowledge sharing is certainly desired, and assisting another Scrum Team is not prohibited by the framework, there are probably more effective ways to achieve the desired outcomes. "Commitments" are not the same as "forecasts" especially in this context. Commented Nov 2, 2017 at 13:39
  • "there are probably more effective ways to achieve the desired outcomes." - Sounds like a good opportunity for another question.
    – Sarov
    Commented Nov 2, 2017 at 14:01
  • @AlanLarimer The definition of empiricism that I'm familiar with is simply that knowledge comes from experience. If teams are on day 6 or 7 of a 10 day Sprint and Team A has met their Sprint Goals and Team B is struggling, Team B has and is experiencing the struggle. Team A providing any kind of help doesn't affect the fact that Team B has new knowledge to reflect upon. Team B can learn and apply solutions in the Sprint Retrospective and Team A can support broader organizational objectives. I just fail to see how this is not the desired outcome and how this is not empiricism at work.
    – Thomas Owens
    Commented Nov 2, 2017 at 22:40
  • A) Renegotiate the scope. If you've got enough capacity remaining and ready backlog items available then why not do another one?
  • B) Refinement. Work some more on preparing the back log for future sprints.
  • C) Housekeeping. Address technological debt, improve tests, do a code review, do a static code analysis, evaluate ways to improve your scrum process
  • D) Exploration: Learn something, coach each other, try an idea for an upcoming task
  • E) "Slack off". You probably hat tight sprints as well. Sprints where you put in additional hours to get everything done. Consider this the flipside.

I would argue, assuming that completing all the Stories has accomplished the Sprint Goal (which is likely but not guaranteed), that the Sprint Goal is now obsolete. Generally, when deciding a Sprint Goal, it should not be something that was already accomplished. By that same vein, once a Goal is achieved, it is then obsolete.

And so, as per the Scrum Guide,

When a Sprint is cancelled, any completed and “Done” Product Backlog items are reviewed. If part of the work is potentially releasable, the Product Owner typically accepts it. All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog.

So, review all the work in the Sprint (the Sprint Review), then return... nothing to the Backlog, since there is no incomplete work.

Then have your Retrospective, where you discuss your success (in achieving the Goal) and failure (in properly estimating the work).

...Of course, as mentioned, this is only if you actually completed the Sprint Goal. If not, figure out what you need to do so, then do it.

This is also assuming that your organization is not depending on those timeboxes. If it makes more sense in your specific case to just pull in more work (whether typical "feature" work or reducing technical debt or doing research or...), then do so.

  • "failure (in properly estimating the work)" is no less than an expression in misunderstanding the nature of complex work. Obsolete does not apply since the Sprint Goal is still applicable and deserves to be discussed in the Sprint Review. Commented Nov 2, 2017 at 13:30
  • @AlanLarimer I don't follow what you're getting at for your first sentence, can you please clarify? And I would consider a goal that has been achieved to no longer be a goal. e.g. If you had a goal to get down to 150 lbs, and then you got down to 148 lbs, at that point, having a goal to get down to 150 lbs would be nonsensical. It can (and should) still be discussed in the Review, I agree. But it's no longer a Goal... I think we just have a difference in interpretation of the word.
    – Sarov
    Commented Nov 2, 2017 at 13:38
  • Complex work involves unknowns and possibly learning; expecting proper estimation of when solving executing such work is an indicator of a misunderstanding of the nature of complexity. How would regularly, frequently, or sporadically canceling Sprints due to early completion affect the Development Team, Scrum Team, organization, users, etc? Commented Nov 2, 2017 at 13:48
  • Of course expecting correct estimates all the time is absurd. No Team is perfect, but that does not mean that they should not try, and consequently take note of and examine when they fail. (This assumes that there is no organizational penalty for the failure. If you're going to be yelled at by the Big Boss for any failure, then no, do not consider an early Sprint to be a 'failure'.) Regarding the affect of cancelling Sprints, that depends heavily on the organization environment - hence why I added the last paragraph to my answer.
    – Sarov
    Commented Nov 2, 2017 at 14:00

Discuss with the Scrum team to:

  • Create more (automated) test coverage
  • Remove technical-debt
  • Execute actions resulting from retrospectives, if not already planned
  • Pull in the most important item next on the backlog, if refined.
  • Any other idea the team has

Just use common sense and let the team decide.

The list I gave is the order my current team does it, most of the time it results in pulling in some more work after they cleaned the code-base a bit.

Your Answer

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

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