Sprint Review - The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved?

Consider the audience, and the context.

The Development Team is not being asked to reflect on what went well, and what didn't go according to plan.   They're not considering what they may want to try differently going forward (Kaizen).   They're simply reporting to the attending stakeholders how the sprint went, what issues (if any) they encountered, and how they resolved such issues.

The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved

The focus is on inspecting the work which was undertaken in that Sprint. Not all planned tasks may have been accomplished for example, or substantial new work might have been discovered. Think of the Sprint Review as dealing with the product, and the Sprint Retrospective as dealing with the process.

There are multiple ways in which this could be useful, but I'll provide one example.



Imagine the Development Team finds that having worked closely with one stakeholder, they were able to release multiple times during the Sprint, and could frequently adapt their approach to the Sprint Goal, based on real customer feedback.

Sharing this information during the Sprint Review may lead to this technique being used again in the future; potentially with other stakeholders. 

Thanks Tim, Ian and Simon for sharing your views.

Ian is correct but I shy away from having the dev team go into too much technical detail. 

I really try and stay away from this in a sprint review. I don't want to bore the audience with this type of stuff. They don't usually care anyway.It's a time to celebrate the good work they have done in the sprint. ---"The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved?".----