When to ask about the sprint - Review or Retrospective

Last post 12:57 am September 20, 2018
by Ching-Pei Li
6 replies
11:17 am September 17, 2018

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

01:32 pm September 17, 2018

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!

09:58 am September 18, 2018

Yep, that clarifies things a bit for me. Thanks :D

11:12 am September 18, 2018

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.

04:42 pm September 19, 2018

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.

06:15 pm September 19, 2018

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.

12:57 am September 20, 2018

General rule of thumb (and likely why Mike Cohn didn't clarify) is consider the audience. 


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.