A live feature presentation is a key component of Agile methods. But if you work in a large organization, or have stakeholders who can’t always be fully engaged, you need more. You need to include capturing each sprint as part of your minimal project documentation.

At any given time, I have several partly fleshed-out columns for this space – but this month I’m deferring them because I want instead to riff on a piece I just read by James Mathewson.

James recommends several hacks of Agile scrum for content design. One of them is “create compelling feature presentations” – which sounds obvious, but often runs afoul of the Agile principle of minimal documentation. James talks about ways of making feature presentations more compelling; what I want to talk about is how a team can share its work beyond the feature presentation.

Feature presentations
Scrum teams work in time-boxed “sprints” (typically two weeks), at the end of which they have deliverables (code, designs, content, etc.) that are ready to go live. Every sprint ends with a feature presentation at which the team shows its work to the project’s sponsor(s) for final approval. However, while sponsors are the main audience, feature presentations are public events: anyone who’s interested is welcome to attend. In terms of format, the ideal is a live demo in which the team shows its work. Merely describing the work (e.g., with charts) is discouraged.

An ideal feature presentation, then, is one which all sponsors and stakeholders attend; which also draws anyone else who would benefit from following the work; and which features a live demonstration of each thing the team has created. This leads to a robust and informed discussion.

Challenges
Unfortunately, I have never attended an ideal feature presentation. Start with attendance: It’s common for sponsors/stakeholders to have scheduling conflicts. And when you’re talking about people who might attend out of general interest … well, not many do. Most people are too busy to devote an hour to a meeting because part of it might be interesting.

For those who do attend, there’s another problem. A two-week sprint is only a small step in a much larger effort. To a Scrum team deeply engaged in its work, it’s obvious how a given sprint fits into the bigger picture. But the casual attendee will often be lost, and even stakeholders may get confused. This gives presenters a daunting challenge: placing the current work in context, for whoever showed up to this particular presentation, off the top of their head (remember, we don’t like much documentation).

To be clear, I’m a big believer in feature presentations. They’re a very useful discipline and a great way of promoting engagement. But as a communication method, they’re seriously limited – especially in a large organization. A few people close to the action will be highly informed, but most other people will be in the dark.

The answer: document your feature presentations
As a product owner, I came to believe that minimum necessary documentation includes documentation of each sprint. I also decided that creating that documentation was my job, for two reasons: First, since the product owner is the liaison between the team and its sponsors (and senior management), I was the logical choice. Second, I didn’t want to pull the team away from their core work if I could avoid it.

So I created a Powerpoint deck documenting every sprint. (Yes, Powerpoint is limiting and easy to make fun of, but it was the most common form of communication at scale in that organization. If you have something better, by all means use it.) The format of the deck was:

Project overview and results to date (one slide)

What we did in the last sprint (one slide)

What we did in this sprint (bulk of the presentation)

What’s coming in the next sprint (one slide)

The charts on the current sprint explained each story we had delivered – what it was and why it was valuable. Whenever possible, it included both screen shots and a link to a live demo.

The sprint deck took hours to create, but it was worth it. It went to everyone on the team, all of our stakeholders and our own senior management. And it was posted in relevant team rooms. This gave our project far more visibility than it would have had if we had relied on feature presentations alone. It created a clear record that anyone could look back on at any time. And it made major reviews easy to prepare for, because we already had all the raw material.

I also saw the sprint decks as a kind of protection for the team: no one could say we hadn’t clearly informed them of what we were doing. This was a concern especially because we had a sponsor who rarely came to feature presentations. His refrain was “you guys are doing great, so I’m going to worry about other things.” This did not reassure me. I knew that someday he would look at what we were doing – and if he didn’t like it, he could reasonably ask “why didn’t you tell me you were doing that?” So we made sure to tell him.

Agile methods include many great ways of “radiating information” to people close to the action – the core team, people paying close attention, people in the same physical space – but if you need to communicate to audiences who are more removed, don’t be afraid to say that documentation is essential.

Charles Chesnut is a digital transformation leader and founder of Chesnut Digital Consulting. He has extensive experience creating new products, websites and organizations, as well as motivating teams to solve complex problems. He was previously Director of Total Customer Experience at IBM and head of user experience design for ibm.com. In other roles, he has managed a worldwide network of web editorial leaders; led a digital marketing innovation lab; and managed large-scale agile transformation projects.