We have been asked to demo almost all bugs in our sprint demo, except the bugs which were raised for the stories of the sprint. Some teams only demo critical bug fixes, probably to reassure others that the bug has been fixed properly.

Is there any benefit in demoing bugs? I don't see any and I think it wastes our time.


It reassures your stakeholders that the bug was, in fact, fixed. It might help them understand what was wrong in the first place, and therefore why it was prioritized.

In some cases it could prompt a broader conversation about desired behavior, edge cases, possible new functionality, etc. Remember, the goal of the demo/review is to use the recently completed increment as a springboard for productive conversations about the product.

If you're concerned about it being a waste of time, I might ask the PO or other key stakeholders to clarify what they want to get out of the demo. I would not frame it as resistance to this request, but rather, "so I can allocate time to make sure your needs are met."

Good luck (and welcome!)

  • I agree. Bugs are a learning opportunity and there is a value in sharing them. – Baracus Jan 8 at 10:30
  • Thanks, especially for this - "I would not frame it as resistance to this request, but rather, "so I can allocate time to make sure your needs are met." – Borat Sagdiyev Jan 8 at 19:39

I am finding it hard to see what value could it bring to have that many people reviewing this on a meeting.

Perhaps you can ask your stakeholders to check bugs offline?

Other two good questions for them are:

How much time is being invested in this? How many times have they found "issues" in the bugs? <-- be aware that if this happens often, then you seem to lack proper QA and UAT in your bug fix process.

  • What could the missing step possibly be ? Examples would be nice. In 1 year, zero issues or concerns were raised for the bugs during demos. – Borat Sagdiyev Jan 7 at 22:56
  • I edited my answer. I was referring to the last bit where I talk about QA/UAT, but if you have not actually have zero issues or concerns then, your process is OK. – Roberto Anzaldua Jan 7 at 23:01

The Scrum Guide is a good place to turn.

The Sprint Review (timeboxed to 4 hours for monthly Sprints) is split into two parts. The first part is for inspection contains a demo, and its essence is:

During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint.

This is to enable the second phase, in which:

attendees collaborate on the next things that could be done to optimize value.

Therefore, your Question can be boiled down to: "Is demoing bugs useful in order to assist in determining the next things that could be done to optimize value?"

...Which is a question which should be answered collaboratively between your developers and the people to whom you are demoing. If the answer is 'yes', it must contain justification. If the answer is 'no', then there's your answer.

Demo bugs if and only if doing so helps you provide value.



We have been asked to demo almost all bugs in our sprint demo, except the bugs which were raised for the stories of the sprint...Is there any benefit in demoing bugs?

The benefit, if any, comes from whether or not the bugs were part of the increment of work planned by the team. If fixing certain bugs was a goal for the current Sprint, then covering it in the Sprint Review is appropriate.

It's likely that the stakeholders want to see that their objectives are being addressed, which is best demonstrated through showing working features. It's unlikely that they're asking for a tour of the buggy code and a demonstration of how the team fixed and refactored the code. Demonstrating a bug fix is often just another feature demo of the sort that one ought to routinely present in a Sprint Review anyway.

If in doubt about the intent, ask the Product Owner and Sprint Review attendees. Making assumptions or asking strangers on the Internet is not a substitute for active collaboration with stakeholders.

Demonstrating Work

The Scrum Guide defines the Sprint Review as follows:

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed.

In other words, if your Sprint Goal was "Fix the Embiggening Widget," then showing that the broken widget is now working is certainly an appropriate thing to do within the Sprint Review. In most cases, this involves demonstrating a delivered feature and some working functionality of the product. The fact that the feature was previously broken and therefore classified as a bug is largely irrelevant from a Scrum framework perspective.

Potential Framework Implementation Smells

Demonstrating non-incidental work items (e.g. planned stories) that were classified as bugs is probably a reasonable thing to do from a framework perspective. However, there may certainly be some whiffy smells that indicate that this is really an X/Y problem with your Scrum process. Some examples include:

  • Bugs being considered non-value work, separate from the delivered increment.
  • Bugs being classified, prioritized, or planned outside of the Product Backlog.
  • The demonstrations being used as a way to "hold the team accountable" for bugs.
  • Focusing on the details of the bugs, rather than on the now-working features.
  • Measuring team performance by bug count, rather than by working features (which are implicitly non-buggy) or reliability of their forecasts.

Most of these smells indicate a process problem, and those problems are often political. It's the Scrum Master's job to address such problems with the team and with the organization.

When Bugs Are the Problem

The one major caveat to what I've written above is when there's a specific reason the team is being asked to demonstrate bugs. If the team is routinely releasing bug-filled code, it points up process problems within the team and lead to broken trust with stakeholders.

A core goal of Scrum is predictable delivery. Not fast delivery, and not money-back-guaranteed bug-free code; just a predictable delivery cadence with a Definition of Done that leads to confidence and trust within the organization about what can consistently be delivered.

If the team is routinely delivering a large volume of bug-riddled code that doesn't deliver working functionality, then this should be addressed within the Sprint Retrospective and an updated Definition of Done.

A real bug isn't just a product feature that should be added or changed. A bug is something that should work but doesn't, and its existence highlights a missing test or process control that needs to be implemented. Some questions to ask yourself include:

  • Should Be "Yes"
    • Does your team use continuous integration, unit testing, behavior-driven testing, test-driven design, and other modern practices to ensure code quality?
    • Does your Definition of Done do enough to ensure consistent product quality?
    • Are all aspects of your Definition of Done included when planning and estimating a user story in Sprint Planning?
  • Should Be "No"
    • Are testing, refactoring, and integration treated as separate from development work?
    • Is the team routinely "delivering" stories that don't meet the Definition of Done?

If you can't answer all the questions above correctly, then the problem isn't that you're being asked to "demonstrate bugs" in your Sprint Review. The real problem is more systemic than that, and needs to be promptly addressed in order to restore stakeholder confidence in the process.


There are a couple factors to consider:

1) What is the timebox of your sprint review?

  • Scrum lays the framework, but it's up to you to maximize the value and efficiency of your team within that framework, especially during scrum ceremonies. If your team expresses desire to shorten scrums, you need to focus on what provides the most value in the time that you have and that is typically spent reviewing new stories.

2) How critical are the bugs?

  • Reviewing minor bugs can tend to lose people, and that decreases efficiency and focus.

3) Who are your stakeholders?

  • If your stakeholders' daily work is impacted by bugs, it's likely they will be very interested in knowing they are resolved, in which case a demo would make sense. But again, if you start reviewing minor bugfixes, you may lose people and essentially burn time, thus decreasing value.

It's possible that your stakeholders don't work in the system everyday (think executives or management), so they may more concerned with high-level details, which likely doesn't include a review of bugs.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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