Develop Agile
How to develop in the Agile world. Focuses on technical and project management styles when developing in an agile software development environment.
Testing Techniques, Scrum Mastering,
Project Management, SCRUM tips & tricks
At this point we have seen how to:
The sprint is now over, the team has finished it’s tasks, it is time for the Sprint Review
Demo what is done
The main purpose of a Sprint Review is to provide the team the opportunity to demonstrate what was completed during the sprint. It is all about demonstrating working software that is done.
In theory done means shippable to your customer, in reality depending on what type of project or company you work for, done may have different meanings. For example if you work on a very large project, done may translate to being able to get your component working on the system testing environment while for our example, done is having the 2nd floor walls up with a roof over our head. 
Sprint Review Logistics
The entire world is invited, this includes the team, the product owner, and any other customers or stake holders. One to two hours is generally enough, the meeting should not exceed 4 hours.
The sprint review starts with the Scrum Master providing some context and any numbers about how the sprint went. The entire team is then encouraged to participate and show the software they have created. This includes explaining the user stories or flows of what is going to be demonstrated then the actual demonstrations themselves. The majority of the time in the Sprint review should be the demonstrations. If the team has performed a sprint retrospective, some output from that can also be mentioned once the demonstrations are finished.
A sprint review is supposed to be informal. The stakeholders are permitted and expected to ask questions so the team can get feedback and has the power to change something if needed in the next sprint. This is one way the team can make sure the customer gets what they want instead of what the team thinks they want. This is a good way for the stakeholders to see how well their expectations were clearly explained to the team without finding out at the end of a release when there is no longer any time to make a change.
Posted by Brian Lawrence.
