Hi, Marco, you are completely right that key results are more related to OKR. But if you observe the article, I have deliberately avoided any mention of it. The reason is that OKR is one of those words that has lost meaning with time... and I just wanted to focus on the essence.

In the case of Scrum, I have to confess that I am not a big fan. Scrum has the problem that tends to guide towards an "Agile" implementation also known as water-scrum-fall. That is in part because Scrum puts too much separation between developers and product people. And that is very visible at the Sprint Review: waiting for one, two, or even four weeks to product know what the developers have being doing is creating a wall too big between roles. Instead, what I am trying to introduce, or at least to hint, that we could repurpose that ceremony to see the outcomes of the current iteration, and learn. That also implies that you have been using Continuous Delivery and releasing during all the PI.

And yes, that is also part of my vision for retrospectives. Anything in the process should be able to be tuned through retrospectives. So, there can be a retrospective saying, we can change it... and then check if it works on that team, or if not, why not, and which is the next step. More or less being adapted.

— — —

I’m rereading the Official Scrum Guide, and it is very subtle about what the Sprint Review is for:

“The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.

During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.

The Sprint Review is the second to last event of the Sprint and is timeboxed to a maximum of four hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.”

It says nothing about reviewing story points, features, demos, … Instead, it says “outcome”, “accomplishments”, “changes in the environment”, … which is really focused on reviewing key results. And, if we consider that a delivery is not an outcome, a story point is not an outcome, so… is it possible that my definition of the new kind of “sprint review” is the one that should be?

— — —

So, thanks Marco for the message, you made me think… and I believe that I learned something deeper than I thought.