Sprint Review: Much More Than Just A Demo

I can add some more anti-patterns, see https://age-of-product.com/...

Semantics is important. Daily Scrum is not a standup meeting. Forecast is not a commitment. Immutable not pick-and-choose.

Death by Powerpoint under Development Team? I like the phrase Scrum a la Stage-Gate.

Yub, I witnessed a much anticipated API endpoint being “demoed” by PowerPoint…

Heartbreaking.

Dear Ilia,

Referring to 'Signs of an Unhealthy Sprint Review', what exactly do you mean by the following phrases?
1. The Product Owner accepts the work completed by the Develepment Team.
2. The stakeholders accept the completed work from the Product Owner.

Sprint Review events are not meant to be sign-off phase-gates as used in project management.

Product Owners need to be involved throughout the Sprint in order to provide clarifications and feedback regarding Product Backlog Items as they are completed. Product Owners do not provide acceptance as that is established through the Definition of "Done", proper backlog grooming, and effective Sprint Planning.

During the Sprint Review event, there is no "acceptance" of the Increment as it is already Done. There is discussion regarding the completed work (Increment) and what might be done next. If the Increment does not address the needs of the customer, then new Product Backlog Items may be created, but the work is not rejected as it has provided an opportunity for learning.

https://www.scrumguides.org...

Can someone explain the phase gate? I thought this was waterfall? Should an acceptance meeting or phase gate be a milestone meeting in an agile project?

Phase gates are generally used in long-term project planning. It is often seen in the "waterfall" paradigm. "Milestone Meeting" sounds like a similar term in a faux-agile approach such as S_Fe.

http://agilemanifesto.org/

Just want to say that, regarding "A review of the budget, timeline, potential capabilities" being included in the Sprint Review... only in the most disciplined companies can I imagine that being effective.

More typically it will simply invite the distraction of stakeholders airing their continuing confusion about, disagreement with, and disengagement from each other and the objectives of the Scrum team's work. A distraction which tends to displace the most critical purpose of the Review... feedback on work delivered. Cynical perhaps, but too often true.

My teams have found it more productive to limit the Sprint Review to presentation that supports the feedback cycle for the sprint's work, with possibly a brief nod (and only at the very end) connecting the sprint to a release cadence and goals. And use a second meeting, like a program status meeting, to meet any deeper needs stakeholders have to see the alignment of the team's work to their mandates. A second meeting with appropriately different and smaller (I hope) attendance roster.

Yes, it's in the Scrum Guide, but if it doesn't work on the ground you have to adapt to what does work. The strategy I describe can be a bridge to the ideal described in the Scrum Guide, which can come in time. That is our hope. But in many companies the bridge will be the end state, and that's the best they will ever do.

They're not truly embracing Scrum, as you point out, but on the ground you have what you have. Something needs to be made to work while the scrum master, product owner, and team are advocating for their own empowerment.

The latest (November 2020) release of The Scrum Guide has removed this aspect of the Sprint Review!

Really nice post, thank you!

Under the section of Inspecting and adapting, just to be a 100% clear does "Releasing Increment (can be done anytime during the Sprint)" mean an increment can be released to the market or deployed at anytime including during a sprint?

Further suggesting that even though the sprint hasn't attained the exact DONE stage, part of the sprint can be released or deployed as an increment pending on the owner/ceo or Product owner?

Continuous Integration and Deployment with feature switching has become a more common practice.
A Sprint is not "Done" in Scrum terms; it ends at the end of the timebox. Individual Product Backlog Items are "Done" when each meets the Definition of Done.

Thank you Alan.

To be more direct in answering your questions... He means exactly what he says. With both of these questions he is promoting traditional, command-and-control, top-down, etc processes. His articles are consistently wrought with information and advice contrary to The Scrum Guide and Manifesto for Agile Software Development.

I think this is wrong.

- "The attendees collaborate on the Product Backlog Items, which can be completed during the next Sprint. Thus, the stakeholders get a shared understanding of the future work."
- "A review of the budget, timeline, potential capabilities follows."

The attendees do not collaborate on backlog items. That's the team's purview. Where is Trust? Where is ownership. The team owns the "How," the stakeholders own the "What." When you ask your car mechanic to fix your brakes, you will certainly not ask the mechanic to go through all the steps required to fix the brakes. He'll fire you and and now you're stuck having to search for another mechanic. At best you might politely ask what's involved in fixing brakes because, you politely explain, you're a nerd and just curious, and it's your dream to work on your brakes yourself. A mechanic will tolerate that because you've identified yourself as someone who is trying to learn instead of control.

Budget? How is that a team concern? If stakeholders want something built then they budget for it. Not a discussion, at least not for the team. Furthermore, we're not project managing. We're sprinting (running fast), to quickly and iteratively deliver valuable things so customers remain delighted and "we" remain highly competitive. Frankly, F.... the budget. If you're serious about being agile then focus on doing. If someone runs out of money, yet asked you to begin building something without some assurance you can see it through to completion, then you're dealing either with a trump-like figure, in other words, someone without scruples who is wasting your time, or someone who is in debt and maybe even bankrupt. Aren't we the consummate professionals who are here to kick some butt?

Project people, burdened with the overhead of PMI dogma, are trying to fit agile into their project management mindset. That's a waste of time. If that's what's happening, you're in the wrong place. Quit and go somewhere else. You're supposed to be a warrior, not some bureaucrat.

if you are having a withdrawal problem or your investment manager is asking you for more deposit before you can withdraw your money from your trading account. Or Do you have funds you wish to withdraw from your binary broker Forex trade or crypto currency account ? or you are having withdrawal problems with your account and you don't know how to go about it. feel free to email Mr ( georgeolsson38@gmail.com) and he will guide you on how to get back your funds in an interval of one week even if you have also lost money to any other company he can still help you to recover any of your lost funds back

It appears as though the blogs that used this Disqus service have stopped. Wonder how much of a part you played in that. :D

makasih informasinya, rupanya Sprint Review lebih dari sekadar Demo.