Scrum when reaching goal beforehand

Question

So I've been trying to read about what we should do if the Sprint goal is reached beforehand and from what I've understand there are 2 options:

• Take in new tasks and change scope
• End sprint beforehand (doesn't sound viable)

But both options doesn't seem very good when you work in a team. To make an example:

Lets say you have 3 team members working on multiple different stories. By halfway through the sprint there is no more new tasks, 2 members are sitting at some tasks that still goes on but 1 member has no more task to start. Now if we take new tasks in so the member doesn't run out of tasks the scope will change and we could continue to do this but we'll never reach a completed sprint. If we don't take new tasks in the sole member will have to help the 2 others (might not be possible) or work outside the sprint (not recommended either) because we can't end it while 2 members still are working.

So how would you guys recommend handling running out of task beforehand but only for some team members?

Answer 1

Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened. The Scrum Guide

"2 members are sitting at some tasks" means that "scrum goal is reached" is probably not true. (Sprint Goal BTW) If all of the Product Backlog items selected during Sprint Planning are not complete, then that needs to be accomplished. The Development Team should be working together collaboratively to complete all of the items in the original forecast.

If all of the initial forecast has been completed, the Development Team and Product Owner should work together to determine the best use of the additional time. There are many options that may be viable:

• Product Backlog refinement
• Adding a new item that can be completed within the Sprint
• Addressing technical debt (avoid technical debt escaping any Sprint)
• Automation improvements (tests, builds, deployments, etc.)
• Knowledge share
• Skills improvement
• Cross-functional training
• Celebrate accomplishments

The Scrum Master may have some other suggestions.

"we'll never reach a completed sprint" is inaccurate, as each Sprint ends when the time-box expires. The forecast may not have been completed or the work may have been completed more quickly; it's okay, these things will happen. Use the Sprint Review to make transparent why that occurred: unforeseen complexity, technical debt in the way, sick days, new technology, etc. If this not completing the forecast happens regularly, us the Sprint Retrospective to create a plan to address the root issue. Inspect and adapt.

Answer 2

So how would you guys recommend handling running out of task beforehand but only for some team members?

"Responding to change over following the plan"

Some ideas in no particular order:

• See if someone else on the team needs help.
• Pay down technical debt (refactor, automate tests, fix "flakey" tests).
• Learn something new; having some free time is a healthy thing. Read a book, write some code for fun, learn an XP skill, etc.
• Pair with someone on something in flight; learn a new skill or help them out even if they have a different role than you.
• Get a head start on next sprint. It's not a bad thing to get an early start, and stories can carry-over. Be transparent about it since this is a team decision. Just be careful that unfinished story code doesn't go to production or endanger the sprint goal.

Answer 3

There are several possibilities and which one to take will change from situation to situation. In the end, the most important factor is that the development team and PO agree that the chosen action is the most valuable for that case.

• If you are close enough to the end of the sprint that it isn't possible to take on new work with a reasonable chance that it can be completed within the sprint, then

  • the developers without work could assist the others to ensure that their work also gets completed within the sprint
  • the developers without work could work on improvements that don't immediately add value for the business but to pay back some technical debt.

• If there is still time enough to complete an additional story, my recommendation would be to add an additional story to the sprint. In collaboration with the PO, this doesn't have to be the top-most story from the backlog but could also be a smaller story that is a bit further down if that fits better within the remaining time of the sprint.