In Scrum, each sprint is required to deliver a potentially shippable product increment. This means that at the end of each sprint, the team has produced a coded, tested and usable piece of software. from Mike Cohn.
I have been working on my Udemy.com course for most of the month of June. It is coming along well and I am learning a lot about online education. The following is an excerpt from my Agile Basics course lecture Sprint Demo.
The Sprint Demo is scheduled at the end of your Sprint. It is a chance for the Scrum team to review their accomplishments from the Sprint. Each Sprint is required to deliver a potentially shippable product. This means the development team has coded and tested this software and it is ready for the demo. It may include some new features and/or some enhancements.
The Sprint Demo can be a large meeting as the whole team is present plus their stakeholders. Management, customers and developers from other teams are welcome. If the Product Owner is communicating well there should be no surprises during the Sprint Demo.
The Sprint Demo should be kept informal. It is not a slick sales demo like Steve Jobs might do. No need for some elaborate PowerPoint presentation. just show them working software. It is important for the team to prepare for the Sprint Demo. They should practice their demo a few times, but the preparation should be minimal under two hours. We don’t want to take too much time away from developing working software. On my first Sprint Demo we didn’t prepare at all and it was a total flop, so take some time and get ready!
The developers and testers should demonstrate the user stories they worked on. This gives them a chance to feel ownership of their work and perhaps get some kudos too! This is a good time to publicly acknowledge the Sprint Goals the team has achieved. The team has covered a lot of ground from the Sprint Planning to the Sprint Demo, though sometimes we don’t celebrate our progress. The Sprint Demo can help stakeholders see tangible progress and build momentum.