Demos

I think Demos are the most important Scrum meeting your team can do. If your team is starting out on Agile journey, Demos are a fantastic place to start it. 

What problems do demos solve?

Demos help keep everyone on the same page about what to expect from the product. A good sprint demo demonstrates the latest and greatest software that the entire team can sign off on. Ideally this is your team's potentially shippable increment. However it should be considered a huge positive if a team can produce working software at the end of the sprint, even if it is not 100% shippable i.e. has some bugs or stubs for functionality.

Demos help the product owner see their vision taking shape. Demos can provide insight into use cases that weren't previously thought about. As I mentioned in my post on Continuous Improvement, most products aren't used the way they were originally designed. Demos help the product owner quickly adapt the product to a changing landscape. This means that a good demo will prod the product owner to re-prioritize the backlog. This re-prioritization helps the team add the most value to the business case.

Whom to invite?

I'm a strong believer of demos being a public event. Anyone who has the correct privileges to your secret sauce should be invited to the demo. Consider a demo as your team's 15 seconds of fame in front of the high profile audience. 

At the minimum, the team, the Scrum Master and the Product Owner need to be a part of the demo. A couple of levels of the team's line management is an excellent addition as well. 

There may be a time when the team does not produce any demonstrable output in a sprint. In such cases, I strongly recommend continuing with (not cancelling) the demo. Rather than hiding the problem, it is best to put spotlight on it. Failure is the best teacher, I love the Agile mindset of - fail early, fail often, fail better.  

A non-demo is an excellent chance for the team to retrospect on why no demonstrable output was produced. As a Scrum Master, it may make sense for you to give a heads-up to executives attending the demo that the team doesn't really have anything to show. However, I encourage asking them to come to the meeting anyway and then make the team say there is nothing to demo. 

What & When to demo?

I want to reiterate what I said above - A good sprint demo demonstrates the latest and greatest software that the entire team can sign off on. This means both development and test portion of the software. 

I have seen teams demo their sprint increments after they are development complete, but not fully tested / with on-going verification. At best, this can make the demo Gods angry, at worst it can give Product Owner and the team a false sense of where the product actually is. The team can lose credibility if something is demonstrated, but not available for Product Owner to meaningfully use / deploy.

I encourage teams to demo known bugs in the code along with working increments. This allows for easy triage of defects. This also provides transparency about where the product is.

I was recently involved in development of a product where the Product Owner wasn't co-located with the team. The Product Owner was also very busy, managing multiple products at the same time. As a Scrum Master, I encouraged teams to make sound judgments about the product and highlight those decisions in the Demo. If the team was blocked on a UX asset, I encouraged the team to use the worst possible asset at that location, and demo it. I found that when we put spotlight on the problem, it got the right attention and quick resolution.

Nothing to demo, ever?

I know that some teams that work on the radio layer or in the database layer. I know of teams that believe there is nothing to demo in those layers. I disagree with that. 

I encourage thinking about creative ways of demonstrating the team's work. It is important for the Product Owner to understand how the product is taking shape. The demo doesn't necessarily have to be a video or a UI. For example - if you are working exclusively on the database layer, the demo can be a stored procedure that runs on sample data set producing some output. 

If you can't think of any way to directly demonstrate increments of functionality, I encourage working with the Product Owner to prioritize building a crude UI or some sort for the product. Although the UI may be completely throw-away code, it allows the team to show off their achievements.

Live vs Recorded demos

I like live demos. However, if a live demo is too much of a hassle to coordinate, I encourage showing videos of the latest increment. I hate the way my voice sounds on recordings, so I use Handbrake to cut the audio stream out. I use subtitles to explain what is going on in the video. Here is an example of a .srt subtitle file. 

Rate this post!

☆

☆

☆

☆

☆