Stakeholders Participation In Sprint Reviews

By Author: Mrugesh Panchal
Total Articles: 48
Comment this article

Attending the sprint review
Sprint review meetings help to support some of the important values, which are so very important in scrum – Inspect and adapt. These values and principles form the backbone of scrum methodology, and each event, ceremony, and artifact used in scrum is subjected to it. Moreover, the Agile manifesto suggests that the most effective and efficient method of sharing information with the scrum team is to have face-to-face interaction with the team members. The “personal touch” is very important in scrum, and it helps to foster collaboration – another important characteristic essential to scrum framework, which helps to streamline the implementation process.

Attending the reviews in person
Personal presence, and attending scrum meetings in person, allow effective communication as well as help in availing proper and reliable feedback from team members. Even though the members can “attend” the meeting using internet based and on-line tools, as is the case with disjointed or remote scrum teams, it is ...
... recommended that each member attends the meeting in person. On a practical basis, there can be no other substitute for a “personal” presence, however effective or powerful other substitutes may be.

Who should attend the meeting?
The product owner should attend the meeting since he or she plays the primary role of reviewing the user stories developed by the team during the daily sprints. The PO is responsible for Okaying the sprint backlog items after ascertaining whether they are shippable and meet the acceptance criteria. The primary role of the scrum master is to facilitate the scrum process and ensure scrum methodology is implemented properly at all times. It is, therefore, imperative for him or her to attend the review too. And, of course, the team members should mandatory attend the meeting since they have to present the completed product backlog items to the PO. Some scrum teams also make it a practice to invite the stakeholders and project owners to the review. It is a good practice to follow, since they own the project, and provide valuable suggestions regarding the acceptance criteria and when stories should be accepted as “done”.

Stakeholders and reviews
Stakeholders are passive participants in the scrum project, but their participation is a very significant one. They own the project. They appoint the PO to execute the project. They remunerate the entire scrum team. And they also enjoy the profits availed through successful implementation of scrum projects. Their feedback is very important for the team. The entire product backlog prepared by the PO is in fact created through the feedback received from them. The stakeholders are also the final entity to accept a particular development activity as “Done”. In many ways, even though stakeholders do not participate actively in the project, they still end up controlling it, for all practical aspects.

Contribution during reviews
The presence of stakeholders can make a marked difference as far as the outcomes of the review are concerned. Stakeholders may not have a technical background, and they may not even understand how the stories have been developed. However, they have a sound understanding, and knowledge, regarding what each functionality and feature should ideally offer, and how the features should perform in the market once they are developed. When stakeholders peruse the results of a user story, they tend to look at it from the end user’s point of view. Based upon that view, they can provide valuable suggestions and tips regarding what is desired out of the user stories and their development. It is because of this reason that the product owner carefully considers their requirements when he or she develops the product backlog and writes the product backlog items or user stories.

When stakeholders regularly attend the reviews:
• The team gets a chance to understand the acceptance criteria linked with the user stories in a much better way.
• The team can ask direct questions and avail answers “first hand” from the stakeholders, rather than having them routed through the PO.
• Development team can explain the technical aspects and difficulties to the stakeholders and end users, and decide upon where to compromise, and how, while developing the user stories. This can be done by updating the acceptance criteria stated in the respective stories.
• A healthy open discussion can lead to generation of new ideas as to how existing processes can be improved upon, and how the team can benefit from the lessons learnt in the prior sprints – Inspect and adapt.
• Collaboration levels are improved upon and scrum implementation can become more streamlined.
• Problems and issues can be openly discussed and their solutions availed more promptly.