4

I am a rookie PM. We are conducting a Sprint with selected tasks from the backlog, when suddenly critical bugs appear. Should we extend the Sprint, or finish the Sprint on the delivery date and move the remaining tasks to another Sprint?

6

Welcome Ayesh!

You have 3 options, and the best option to choose will depend on the details of what is going on:

  1. Ignore the critical bugs for now. Finish the sprint you're doing now, and put the bugs at the top of the backlog to be worked in the next sprint.

This can be a good option when the sprint is going to be complete in a few days anyway, or when there is low risk and/or low cost in waiting on fixing the bugs.

In general, this should be the preferred response for all "suddenly, new stuff appears", whether the stuff is bugs or requirements or new priorities or whatever. Sprints are short iteration cycles, short enough that in most cases, it should be reasonable to wait until the next cycle to address stuff. If the critical bugs were just discovered, then presumably they've been there for a while and you've lived with them this long, so what's another week or two? This is often reasonable logic.

  1. Add the bugfixes to the current sprint by removing an equivalent amount of work from the original plan.

This can be a good option when fixing the bugs quickly is of more value than completing the original sprint goal, and when there is indeed an equivalent amount of work in the current sprint that can be swapped out.

  1. Cancel the sprint, and immediately plan and begin a new sprint focused on fixing the bugs.

This is a drastic and disruptive option; canceling the sprint is generally a last resort. It would be appropriate when the bugs are not only critical but urgent, and fixing them immediately has more value than anything else, including the cost of context switching and lost planning.

Personally, I don't consider "extend the sprint" to be a viable option. Work is planned in sprints (short fixed-duration timeboxes) so that change can be embraced between sprints, and focus can be maximized during sprints, and the team can gather useful metrics like velocity normalized by the constant sprint length. Extending the sprint messes with all that. (And, again, if you extend the sprint in this case, are you going to start getting pressure to extend the sprint for other reasons that various stakeholders might consider critical? Better to not even go there.)

Good luck!

  • Thanks for the clear clarification. I guess, I'd go with the option 2. – Ayesh Perera May 2 at 2:54
2

TL;DR

Should we extend the Sprint, or finish the Sprint on the delivery date and move the remaining tasks to another Sprint?

Scrum is a time boxed framework that values a predictable cadence of events. Work that can't fit into the current time box must removed from the current time box, or the entire time box scrapped so the Scrum Team can adapt to newly-discovered priorities.

Categorizing and Managing Bugs

In Scrum, Product Backlog Items are either done or not-done at the end of a Sprint. The Sprint is a fixed time box, and should never be extended to fit scope. So, incomplete work or features that don't meet the Definition of Done should go back on the Product Backlog to be re-prioritized by the Product Owner and re-estimated when they are again in scope for Sprint Planning.

Correctly categorizing your "critical bugs" is important, too. In Scrum, bugs will generally fall into one of four categories:

  1. If they are actually issues with the current work increment, then fixing them should be part of your Definition of Done and addressed in the current Sprint (if possible). Unfinished work is addressed during the Sprint Review, and then placed back onto the Product Backlog.
  2. If the bugs aren't directly related to the current Sprint Goal, or are refinements or other work that was not in scope for your current Sprint, then they belong on the Product Backlog for a future Sprint.
  3. If the bug is truly "stop the line" critical, the Scrum Team can collectively renegotiate scope for the Sprint to free up capacity so long as the current Sprint Goal is not endangered.
  4. If the bug is so critical that it takes precedence over the current Sprint Goal, then the Product Owner can cancel the Sprint as a visible cost to the project. The team can then return to Sprint Planning, where this critical bug can be prioritized, estimated, and planned. NB: If the bug isn't critical enough to do this, then it's probably not really that critical.

A core agile tenet is that not everything can be "priority number one." If the business has identified a truly critical bug, then either fixing the bug is more important than the Sprint Goal, or else it isn't. If it is more important, then the cost to the project of cancelling the current Sprint and replanning is fully justified. If it isn't, then the Sprint Goal should not be put at risk for a less-important issue. Prioritizing work is the Product Owner's job, so you should work with the Product Owner to determine whether he or she is prepared to cancel the Sprint.

Continuous Improvement

Whatever you do in regards to this particular bug, make sure you take time to address this as a process issue within the Scrum Team during the Sprint Retrospective. Bugs happen, but the team should implement solid practices that limit the number and criticality of bugs, as well as well-defined processes for categorizing and managing them. There's probably some room for improvement in the team's practices and processes, so use this experience as grist for the mill.

0

My two cent input

If the bug has been caused by some work done in current sprint and is kind of show stopper for the release, then it must get resolved in current sprint. Analyse it for the effort required to fix and free up resources by moving equally weighed work back to product backlog without much effecting goal of the sprint. Even if the goal of the sprint gets a CUT, PO can discuss this with stake holders and convince them.

If the bug has been there in previous releases and somehow could get discovered now, then it can wait for the next sprint.

Please note, aborting a Sprint is not an option here. It is mostly done in situations when the work being done in sprint is no more relevant. e.g. feature being developed is not required by the customer any more. (Bug is not a valid cause here)

Sprints are time boxed so should not be extended.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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