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