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!)
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.
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.
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.
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:
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.
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:
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?
2) How critical are the bugs?
3) Who are your stakeholders?
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.
