Demonstrating in the Sprint Review

In an agile methodology each sprint concludes with a review
of what was accomplished during the sprint. These reviews are opportunities for
the agile team to demonstrate to the stakeholders what is completed, what it
looks like, what it does, and other features of the software. These sprint
reviews are also vital to the identity of agile because it is when feedback can
be received from many stakeholders. This continuous feedback to help promote
change at the earliest possible time is really what separates agile from other project
management strategies. It also allows development teams to spend more time meeting
and adjusting to customer needs.

Often times the sprint reviews may be referred to as the
demo. Labeling the review as a demo can have it benefits but also its setbacks.
When a meeting is scheduled and the title of the meeting is, ‘demo’, the
meeting has a much higher chance of having a large turnout of employees.
However, generally during a demo there will be a person or group presenting and
everyone else just listening and watching. Even though your review may consist of project demonstration, the overall goal of the review is to get real-time feedback from the project’s stakeholders. So, if you are to label the sprint review as a demo, just be clear
that all attending stakeholders are aware that they should be giving feedback
and not just listening.

Each sprint is effectively over once the demo has been
completed. The average scheduled length of these demos are around two hours.
Although note that this is the average scheduled time and not the actual
average time spent in an agile demo. Many organizations will view the two-hour
mark as the maximum time that will be spent in the meeting. If the project has
many high-level stake holders then convincing them to sit in a two-hour meeting
may not always be the easiest option. A high frequency of agile teams will
begin sprints on Thursday mornings, this way organizations can avoid large and
important meetings on Friday where it may be impractical for some.

During the demo, the product owner should be the one driving
the meeting and describing the product to the stakeholders. This is where the
product owner is trying to convince the stakeholders to justify their current
investments.  During these meetings, the
agile team (not scrum master or product owner) will sit back and let the
product owner drive the meeting. Team member should be paying attention closely
and taking notes, as a stakeholder might make a good suggestion that needs not
be forgotten.

One last important reason for the demo is for the product
owner and stakeholder to achieve a more aligned vision of the how the finished
product should look and function. In the end, it is the stakeholders that fund
and sign off on the product being released, so it must be designed to their
vision of the product. The better understanding of the desired product a
product owner has, then the more efficient sprints the agile team will have.

Work Cited:

"Agile at Work: Driving
Productive Agile Meetings." https://www.lynda.com/Business-Skills-tutorials/Demonstrating-sprint-review/175075/438004-4.html.
Accessed 20 Nov. 2017.

Image Provided By:

https://www.srijan.net/processes/real-time-user-testing-using-demo-script