As more and more organizations adopt more iterative methodologies like Scrum or Agile it’s imperative that their teams understand how to effectively give good sprint demonstrations. The end-of-sprint demo is a critical piece of the whole iterative approach. The sprint demo is intended to provide your users/customer a sense of what has been achieved in the last two weeks (assuming you’re using two week sprints) and how what you’ve built applies to their business requirements (i.e. what problems have you solved and how did you solve them?) Here are some tips on preparing for a great sprint demonstration.
Some of the best demonstrations I’ve taken part in have been where the person leading goes into great detail about not only what has been developed but why it was developed a certain way. And when describing the “why” the reasons cited are more focused on the business value rather than any sort of technical reasons – for example, citing why a screen layout was developed a particular way indicating that it was easier for an end user to comprehend and quicker for data entry flow. Demos that not only inform the users of what has been developed but how the delivered functionality reflects the business needs are vital to helping adoption of the product.
Treat it Like a Training Session
At the conclusion of each sprint demo, users should be encouraged to start using the delivered functionality in a quasi-testing mode. The full breadth of functionality is not delivered until all of the sprints are complete but what is delivered should be working as close to 100% as possible which means that users are going to be getting into the system and trying it out. For this to happen effectively, the sprint demo should not only demonstrate how the system works, but also teach the users on how to use the functionality. The person delivering the demonstration should go into the demo with the mindset of educating the users along with “wow-ing” them with what’s been built.
The entire premise of iterative development is to get functionality in front of users early so that changes can be addressed as early on as possible. Change becomes more expensive the later in the project that it happens so it’s vital to get things in front of the users as early as possible. Once users have seen the output of a sprint and are educated enough to start actually trying it out, it’s important for the users to provide feedback on the system (positive and constructive) so that any changes needed to what’s been delivered can be addressed with minimal impact to the project. Whether or not feedback is within scope is a topic for another post but any feedback that passes a change management gate should be addressed early and often.
Platforms for providing end user feedback are plentiful but even something as rudimentary as an Excel spreadsheet can be used to gather and transmit feedback to the project team.
Sprint demos are a cornerstone of the iterative methodology. Done effectively they will quickly convey what’s been done to-date and allow your users to quickly and easily dive into the system and begin exploring the functionality that your team has delivered.