The Sprint Review for Developers
In Agile software development, the Sprint Review Meeting is a demonstration meeting held at the end of every sprint. In it, the Scrum team showcases new features finished in the sprint. To some, this may seem excessive or unnecessary. Why have a review meeting after every sprint when you can just have one big review meeting at the end of the project? However, having a sprint review meeting at the end of every sprint yields several benefits.
The biggest benefit of the sprint review meeting is that it keeps all parties informed. Even roles who did not directly work on the project get regular updates. Stakeholders see features in action, within weeks after they are finished. Instead of going months or even years without new features, they see the fruits of new development often. In turn, developers and other scrum team roles see stakeholder reaction to their hard work. This can help steer future development.
Similarly, the sprint review offers an open forum for questions. Not only are stakeholders allowed to give feedback, they are encouraged. If they like or dislike features, or need clarification on how something works, they can voice these concerns. The scrum team then sees where they may need to explain things better, or how to change development moving forward.
Roles in the Sprint Review Meeting
Most people consider the product owner the key role of the sprint review meeting. For most parts of the sprint review, the product owner is the role who approves or rejects the sprint deliverables. Product owners are responsible for interacting with stakeholders, and the most important purpose of the sprint review is showing stakeholders what new features are in the product. No other roles of a scrum team have customer-facing responsibilities.
On the communication front, Scrum Masters would also have a responsibility in the sprint review meeting. The Scrum Master is typically in charge of coordinating different roles and guiding the Agile development process. As such, it would be up to the Scrum Master to make sure everyone on the team is informed.
So what part do developers have in the sprint review meeting? It would make sense for developers’ work to be done before the sprint review. New development is done, and features have been tested if they are to be shown at the meeting. The sprint review meeting is just demonstrating what the scrum team accomplished. The developer role offers value to the sprint review meeting, most notably, developers have the expertise to answer technical questions. They know what goes on under the surface with a product. If stakeholders have questions that other roles cannot answer, developers should know the details.
Along with explaining details, developers can assuage concerns. If stakeholders are worried about vulnerabilities, developers can explain what security measure is in place to prevent them. If concerns are impossible or unlikely to happen, developers can elaborate on why. On the occasion that stakeholders do bring up valid concerns, developers have the opportunity to explain how it will be addressed moving forward.
The biggest benefit that developers stand to gain from the sprint review meeting is first-hand exposure to stakeholders. This is especially true with accepting or rejecting deliverables. One of the biggest problems with traditional development is how feedback gets filtered through different people. Customers respond to marketing employees, who send this information down the pipe to developers. By the time developers hear the information, it may have lost the majority of its original meaning. This watered down summary is rarely helpful to developers. How can they make productive changes when they don’t really know what the customers wanted?
Our Favourite Agile Books
We found these books great for finding out more information on Agile Scrum: