The Agile Project Manager—Voila: The Great Reveal

The Agile Project Manager—Voila: The Great Reveal

You are currently viewing The Agile Project Manager—Voila: The Great Reveal

7 Key Focus Points for your Sprint Reviews

1) Ownership  – We established that the Product Owner ‘owns’ the overall pattern for the Sprint Review. Sure, it’s a “whole team” thing. But at the end of the day, external communication, showing planned-delivered value, and gathering & adjusting to feedback are primary aspects of the PO role.  They’re also responsible for getting people in the review—so if attendance is spotty, they’ve got work to do to figure out why and to change your patterns to get the “right people” in the room.

Very often I think of their role as one of Master of Ceremony—where they are conducting all aspects of the review. Certainly not doing everything themselves, but guiding the overall quality, focus, and results of the review.

2) Format  – We put a lot of thought into the scheduling & timing for the review (or reviews if you’re part of a multi-team initiative). You’ll want to get into a regular tempo (day & time) for your reviews. Within the context of the review, you’ll want each team to follow a consistent flow (see potential review agenda below).

In our case, we had multiple teams demoing on the same day—as our sprints were synchronized. So, our format was really a cross-team agenda that sliced a 3-hour time slot into appropriate stages for each team. Not only did we plan each review, but our Chief Product Owner took a stab at conducting overall flow across the teams.

3) Sprint Goals  – I personally like the view where the review is “hinged” on the sprint goal(s) that the team(s) signed up for. Quite often I tell teams when they’re crafting their goals to think about the e-mail invitation they’ll be sending out for the reviews. The ‘story’ of the sprint then is tied to the goal and how the team reacted towards meeting the goal.

And you should be honest about how the team delivered to their sprint commitments, so “Call It” as a success or failure. But never, ever let the term ‘failure’ be used to browbeat the team. Failure is a part of teams learning and the organization needs to adopt a “Fail Forward” attitude.

4) Whole Team View  – As I said, I like the view where the Product Owner is the Master of Ceremonies, the Scrum Master is the facilitator (if needed) and the entire team gets a chance to “show off” their results in each review. This whole-team approach serves to give your team transparency and the chance to shine—so round-robin your demo individuals and give everyone (person, role, etc.) a chance to show off their work and results.

And no, don’t ‘force’ introverts to speak uncomfortably in a large forum. Make it encouraged and optional. Very often these folks can serve as the ‘driver’ for the demo—so quietly participate. But do engage the whole team!

5) Preparation  – If there’s a key to a solid sprint review its preparation—somewhere safely between “way too much” and “totally winging it”. You should put some thought into what work is relevant for the review, in what flow should it be demonstrated, and how it connects to previous and upcoming sprint work.

Quite often someone with a QA background will develop a review ‘script’ that helps the team expose their efforts in a cohesive way. Ultimately, the Product Owner should have the strongest voice into what gets exposed and why—setting the stage for the ‘reveal’ with the stakeholders.

If in doubt, reserve sufficient time in sprint planning for review preparation and DO prepare.

6) Execution & Demonstration  – The review demo needs to be smooth, thoughtful, polished, and ultimately—the software needs to flawlessly work. Dry-running the demo and having everything pre-setup is a must. You should also do timings to ensure your demos fit into your allotted time. And don’t forget about Q&A time.

Beyond the demo, you need to tell a story that encompasses your feature workflows. I’ve seen teams in their first sprint show an architectural diagram that reflected the work they planned for the upcoming six sprints. Then in each sprint review, they “filled in the boxes” as they began fleshing out the application architecture. I thought this approach was an outstanding way to “connect the dots” for the audience.

From my perspective, ALL WORK that a team took on in a sprint is a candidate for exposure. That might include: features, enhancements, bug fixes, refactoring, documentation, testing infrastructure, virtually everything. Sure, some things might require some finesse to demonstrate or illustrate, but if its work the team did—it’s a candidate for the review.

And finally, be ready to explain things sufficiently so your audience UNDERSTANDS what you’ve just shown, its significance, and the level of effort behind it.

7) Wrap-up  – Finally, we always wrapped up reviews with a general request for feedback—both on the software itself, but also on our review dynamics. Were the transitions well made? Did we explain what we did? Do you know how to send us your feedback? And what can we change to make the next review even better?  We usually only spend a few minutes here, but it’s time well spent. If you’re familiar with the notion of a Fist-of-Five, we usually leveraged that technique for closing feedback.

Sample meeting agenda

Consider the following as a healthy template for your teams sprint review agenda—


Team Chart

  • who’s-who: names, roles, and location of team members
  • external folks who helped with the sprint

Acknowledgements – Appreciations

  • certainly shout-outs for team members
  • but also a good time to recognize “external folks” who were instrumental in the sprint

Sprint Goal

  • articulate the Sprint Goal, speak to any adjustments that were made during the sprint
  • call it: was the sprint a success, i.e., did the team meet their commitment to the sprint goal?

Strategy? Success? Efforts? Discoveries? Results?

  • share any relevant strategies the team used to deliver the work
  • explore the effort behind the sprint
  • were there any discoveries that were unexpected; any critical results
  • all of this is to give the audience a “behind-the-scenes” look at the teams sprint

Demo’s; Q&A

  • demo the selected set of user stories / features – allow for Q&A

Coming Attractions

  • speak to progress to release goal(s) and upcoming work in future sprints

Fist-of-Five Towards Improvement

  • engage the audience in review performance feedback


Wrapping up

I simply can’t tell you how good it feels to have a high-impact sprint review. And while I put a lot of pressure on the Product Owner and team for the results of the review, as an Agile Project Manager you play a central role as well.

Teams often get “caught up” in the work of the sprint and short-shrift the review preparation. In fact, this is a common anti-pattern. You can turn this around in sprint planning—asking the team to plan for and allocate sufficient time towards the review, while also reminding them as the end of the sprint approaches to consolidate their work.

Remember, the review is also a “QA checkpoint” for the team. There’s nothing like pulling things together and demoing them—to bring a healthy dose of reality to a teams’ sprint efforts. You always shake things out—environments that don’t work, integrations that weren’t made, and interactions that were forgotten.

So Agile Project Managers, I hope this post has inspired you to take charge of your reviews and make them the most powerful event within your agile teams. While it is certainly the teams’ responsibility to prepare and deliver, you can influence the attitude and approaches. You can also amplify the positive feedback you’ll get as you improve.

Thanks for listening,


BTW: a presentation of this material was shared at the 2012 Atlanta Scrum Gathering. You might find it interesting as it compliments this article.

Leave a Reply