The primary purpose of the Sprint Review meeting (sometimes also referred to as the demo meeting) is to evaluate whether the Scrum Team achieved the Sprint Goal (see figure below). It generally includes the development team, product owner, scrum master, and stakeholders reviewing the working code and sometimes the results of automated test cases.
Communcation – Personal and Technical
A good Sprint Review meeting needs, first of all, good communication. That can be a challenge when different members of the distributed teams have different primary languages. Choose a member of the development team carefully who can communicate effectively with the team, the product owner, the scrum master, and the stakeholders should present.
Keeping the demo environment ready and resolving network issues is also very challenging. In one of the projects, I was working with my development team in India for the maintenance project, and during a review as the technical lead I would ask: “Show us that house.” There would be a delay and then, the house would come up on screen, then another delay, and my team mates at offshore would ask the product owner what he thought about it. He would say: “Great, can you spin it to the left?” Again, I’d hear the development team run into another room and then the house would spin. As it turned out, there was no Internet access in the conference rooms where the phones were, so the team members had to run to the lab to make changes. Because the product owner was not local, he had no way of knowing they had this problem.
After seeing the problem continue through a series of deeper and deeper reviews, we came up with other approaches like recording the screen navigation for meeting and sharing the recording with attendees. One other approach was to hand over the application to users and ask them to navigate the screens as per the acceptance criteria. This would give them a feel of the application and helped in building confidence.
Who to Include?
Although including all stakeholders sounds intuitive, teams that are transitioning to agile often use the review meeting to show the Sprint to the Scrum Team but not to the product owner or business users. Not engaging these stakeholders in the review increases the project risks over time because the Scrum Team may drift farther out of alignment with the stakeholders’ expectations.
However, the number of people attending the review meeting should be controlled. Otherwise, the meeting could wind up increasing the scope, requiring additional work in future sprints. Remember also that not every representative stakeholder will take part in a review at the end of every sprint. If the Scrum Team is on a two-week Sprint, for example, the likelihood of having principals attend every two weeks is unlikely. Still, the Scrum Team should strive for frequent feedback from all categories of stakeholders.
Don’t Overcommit
New Scrum Teams inevitably overcommit in their first Sprint. Shifting from 18-months to 2-weeks to deliver value is a major shift for such teams and they often don’t realize how much of a challenge it is to finish user story — everything from coding to testing – in such a short period. Because new teams often spend the first Sprint or two learning how to break down work, teams may want to wait a Sprint or two before engaging stakeholders, particularly principals, who will expect firm results from the sprint.
In some cases during the review, a stakeholder will try to add additional feature to the current story and presses for them to be implemented during the next sprint. That can make life hard for the team since they are already settled with tasks for that sprint. To avoid this, I recommend having the product owner sign off on the product backlog before the review, to prevent further features being added at that late date.
Harshal Sanjay Deole is a software developer with seven years experience in outsourced software development using both waterfall and agile scrum methodology.
latest news in global ITO and BPO with a focus on Guadalajara.
