3

Click here to load reader

Why we say review meeting when we are really doing a demo

Embed Size (px)

Citation preview

Page 1: Why we say review meeting when we are really doing a demo

Why we say “Review Meeting” when we are really

doing a “Demo”?

Each words that we are using have a specific meaning, each event has its own motive and knowing the name of each event the attendees know what they are going to find. It is necessary to define every relevant agile, Scrum, and software-development term that the team is used. This is one of the Empirical Process pillars, Transparency, when all the team understands the same.

“A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed.”

The focus of the sprint review is to inspect and adapt the product increment that was produced during the sprint. We inspect what was just built and, based on the feedback that we get from our stakeholders, we can adapt what we build next by Sprint Refinement Meeting the product backlog.

“During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint.”

In some Scrum Teams, the Sprint Review is used to get the Product Owner’s feedback, then the Sprint Review becomes a kind of ‘Acceptance’ event and not A Sprint Review Meeting. In such Sprint Reviews often no stakeholders are present. The Product Owner is the only person to give feedback. Here is the gap: The Product Owner is also part of the Scrum team. Feedback from the Product Owner must always be processed during the Sprint. After all, if you do not process P.O. feedback within the Sprint then you consciously postpone work to the next sprint. And, even worse: you actually prevent that the product is really finished at the end of every Sprint. If the Development Team wants to show or explain any detail about one user story they can plan a specific meeting for that. If the Product Owner wants to know which is the Sprint’s current status, he might see it in the Scrumboard. If any stakeholder wants to know which is the Sprint’s current status, he could take a look to the Scrumboard (if he/she has access) or should ask to the Product Owner.

“Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration. This is a four-hour time-boxed meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches all to keep it within the time-box.

The Sprint Review includes the following elements:

Attendees include the Scrum Team and key stakeholders invited by the Product Owner; “

Page 2: Why we say review meeting when we are really doing a demo

In the meeting the Scrum Team test whether the ideas they have are correct. This test is done with all stakeholders that have an interest in the software. That is why the Product Owner invite all stakeholders to attend the Sprint Review. The meetings consists of many checks and tests to see if you we are on the right track.

The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”; “

The first step is to review the goal and committed/forecasted features and compare that to what actually got accomplished during the sprint

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

The meeting is crucial to learn what a team has misunderstood or what has been forgotten.

The Development Team demonstrates the work that it has “Done” and answers questions about the Increment; “

The demonstration is useful to the extent that it enables a thoughtful discussion on what we just built and its ability to inform any changes we would like to make for what we will build in the future. The real purpose of the demonstration is to enable the next two steps: discuss and adapt.

The Product Owner discusses the Product Backlog as it stands. He or she projects likely completion dates based on progress to date (if needed); “

During the Sprint Review all stakeholders are present. This is the place to show them what you plan to do. Why wait until the end of the next Sprint to get their feedback? In the Sprint Review meeting let the Product Owner show the Product Backlog and embrace the feedback from the stakeholders

The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning; “

A demo of working software may be a good trigger for such feedback. It is for end users awfully difficult to give feedback on software through reading a document. But giving feedback on real working software is much easier. In other words, you will understand it only when you see it.

Page 3: Why we say review meeting when we are really doing a demo

Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next; and,

Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated release of the product.

The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.”

The most important aspect of the sprint review is the in-depth conversation and collaboration among the participants, not the demonstration. These discussions enable productive adaptations to surface and be exploited. A review isn't a one-way flow of information, where the team is doing all of the showing and telling. It's an opportunity for the Scrum team members to get feedback from customers or users. The sprint review therefore represents a scheduled opportunity to inspect and adapt the product.