The Sprint Review meeting is an important part of the Scrum process. Its not only a platform to showcase your work, but a place to place to invoke discussion with the stakeholders on the product that you are creating. It also helps keep the project on the right direction as it ensures that the customer can view the progress earlier in the process rather than at the end of the project where it is too late to make changes without the project over running.
The Sprint Review should be the culmination of meetings by the product owner with the customer where product specifications have been hammered out between the two and given to the team to build. Any deviations from this specification must have been relayed by the Scrum Master to the Product Owner and thus onto the Stakeholders for approval as to avoid any embarrassing situations in the Review where the product does not seem to meet the requirements of the customer(s).
The Sprint Review is often the first time that the stakeholders set eyes on what the Scrum Team have been working on in an iteration. The team start by stating their overall scrum goal that was determined in the Sprint Planning Meeting at the start of the iteration. Ideally the team would have completed each backlog item that was brought into the sprint at the Sprint Planning Meeting but it is more important that they have completed their overall goal rather than completing all stories.
The team will then demonstrate the functionality of each user story or new piece of functionality to the Stakeholders. As we are a development group of a web based company, not all of the stakeholders can be in the same room at the same time, so we counter this by sending out the location where our new functionality is held for the stakeholders to access. We then communicate with each other through conference call or Skype to demonstrate the product, giving the stakeholders a more hands on approach as they are able to ‘play’ with the product.
It is often at the end of the review where questions are asked of the product by the stakeholders and refinements can be planned by the team.
When I inherited the role of Scrum Master of my team the Scrum Master and the Product Owner had not been holding the Sprint Review meeting. There had been one meeting where the product that the team were demonstrating was not fully functional. There were some known bugs in the code and these were demonstrated at the meeting. The meeting was not productive and morale within the team towards the Sprint Review meeting was low.
My first main role as Scrum Master of my team was to facilitate the construction of a large piece of functionality that had a lot of back end and front end work. At the beginning of the project the functionality that we were constructing was not deemed to be reviewable and we did not demonstrate the work to the stakeholders. Over the following iterations we were not having a regular review meeting with the stakeholders, which was against the rules of scrum. We had found ourselves working hard to get the stories completed and we had gotten into the mid set that time would have been wasted by having a review meeting if the customer could not see anything. We will put this down to inexperience on my part 🙂
I then attended a Certified Scrum Master course held by Tobias Mayer and Mike Sutton held in London. Both stated that the great need to have a review meeting to not only showcase your work, but to make sure that it was heading in the right direction. I returned to the office vowing to have regular Review Meetings from now on.
The first review meeting that we had was towards the end of production on our product. We showcased our work and were met with some change requests. Some were thought to be fundamental and may push us over our deadline. We managed to make the changes and have our product out a week past our deadline. If we had held regular review meetings, we could have caught these change requests earlier in the process and put them right.
The team has now moved onto their new project. We recently had our first Review Meeting with the stakeholders. The meeting went well, the stakeholders were happy with the progress we have made on our new product and the team are happy that they actually have some good feedback which was a morale booster.
I cant emphasise enough the value of the Sprint Review Meeting it helps keep everyone focused and happy. Compared with the waterfall method of reviewing the product at the end of the lifecycle, the process of regular reviews could save you from a horror scenario at the end of the project when you find out it is not what the customer wants.
Thanks for reading.