Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
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?
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:
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.
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.
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.
Discuss with the Scrum team to:
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.
