When to ask about the sprint - Review or Retrospective
In an article by Mike Cohn and on the subject to the Review ceremony
"After all completed product backlog items have been demonstrated, discuss key events or problems that occurred during the sprint."
I often see confusion between what should be discussed here (In the review) and what should be covered in the Retrospective.
Does anyone have any useful guidelines that could be followed to keep the separation between these?
eg what should be discussed in the review/what shouldn't etc
I guess he could have added a few more words to clarify :D (or he made a serious error - which I very much doubt).
In essence, those "key events or problems that occurred during the sprint" refers specificially (or mostly) to the product; they can relate to technical difficulties, coding errors, wrong journeys (DT started coding against a test, only to discover the test was incorrect; etc), software clashes and so forth. So the review is (or should be in case it isn't now) 100% focused on the product.
For relationships, use of tools, processes - the retrospective is to be used.
Hope it's clear and helpful!
Yep, that clarifies things a bit for me. Thanks :D
Hi Stuart,
During the Sprint Review we:
Inspect the Product Increment
Inspect the Product Backlog
Optionally inspect the Release Progress
Adapt the Product Backlog
During the Sprint Retrospective we:
Inspect the team and collaboration
Inspect technology and engineering
If needed inspect the Definition of Done
We adapt on the items raised in aforementioned notes by creating actionable items and putting these on the Sprint Backlog to make it visual
Hope this helps.
General rule of thumb (and likely why Mike Cohn didn't clarify) is consider the audience. The Review is designed for the stakeholders, the Retro is designed for the team. The Review would not be the appropriate place to discuss that John (dev) chose to take 4 days of vacation in the middle of the sprint with no warning and no notice given to the team. On the flip side, it would absolutely be appropriate to discuss database connectivity issues in the Review; especially if one or more of the stakeholders has ability to clear up that problem for the future.
The Scrum Guide says that during the Sprint Review:
The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved
Hence key events and problems might well be discussed. Any outcomes which have implications for the team’s way-of-working might then be fed into the Sprint Retrospective.
General rule of thumb (and likely why Mike Cohn didn't clarify) is consider the audience.
+1
Sometimes, the Development Team explains in the Review meeting the obstacles and problems encountered during the development process to let participants know the cost and difficulty of development.
It is also possible to discuss whether there is a lower cost alternative that the Product Owner and stakeholders can accept.