After the completion of a sprint, there are two Agile activities that occur - the sprint review and the sprint retrospective. In this post we'll be covering why the sprint review and why it is so important.
At first glance, a sprint review could be viewed as a show and tell for the developers to show off what they completed in the previous sprint. But, if you dig a little deeper, you find that it is one of the most important meetings in the agile process. A sprint review drives the incremental development of the entire product.
Who is Involved in Sprint Reviews?
Typically, sprint reviews are 1-2 hour sessions. The attendees are normally made up of the development team, the product owner and any stakeholders that the product owner feels should be at that specific sprint review. Sometimes, it may be important for the product owner to have end users at the sprint review to provide feedback and see the direction the product is going in.
What happens in a Sprint Review?
A sprint review always starts with a live demonstration of the incremental working product (never a report). After the demonstration, the product owner reviews what the development team committed to and marks the stories that the team accomplished "done" if he believes the team fulfilled their commitment. Items that the team committed to that are not completed up to the product owner's definition of done, are returned to the product backlog and prioritized according to the product owner's revised priorities.
Once the demonstration is completed and items are marked done or returned to the backlog, the output of the sprint is then open to feedback from the product owner and stakeholders. The Scrum Master helps the product owner and stakeholders convert their feedback to new user stories in the product backlog. This is an extremely important step in, not only a sprint review, but in the Agile software development process in general. The ability to allow input from stakeholders and users and have that implemented directly into the product ensures that expectations are being met and the right product that fits the users needs is being created.
An iterative and value driven approach to building software allows for the creation of products that couldn't be built with an upfront requirements document. This is what makes Agile, in my opinion, the best way to develop custom software.
To learn more about the agile process, be sure to download our FREE Ebook, "The Official Agile 101 Software Development Handbook."
