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.
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.