I remember the day as if it was yesterday. It was my first sprint review at a company I’d just joined as an agile coach. They’d been ‘doing’ Scrum for several years and I had gotten the general sense that they were well disciplined and mature agilists.
So when they scheduled a series of sprint reviews to expose the x-team efforts of their latest sprint cycle, I was understandably excited. So I got into the room early to get a good seat and was eager with anticipation.
Gradually, the room filled and it became quite noisy, which only drove my anticipation higher. Then the first team took “the stage” and began their review. They popped up some PowerPoint slides and away they went…
Their deck was polished. They had lists of things they’d done and down-loaded pictures and jokes for lightening the mood at appropriate points. They marched through the work that they’d done…one slide at a time and at appropriate points the audience politely applauded their approval.
But it struck me mid-way through the first review that something was missing—something really, really important. There was no working software. How could this be I thought. The whole point of the sprint review was to expose working code to stakeholders for review & feedback. Then I thought—this was probably an exception or special case—specific to just this team. Surely there’s working software coming up next.
But, one-by-one, each subsequent team followed the same pattern—showing humorous slides and textual representations of effort, but no working code to be seen. Slowly and then more quickly my enthusiasm waned and I became quite frustrated. Not so much with the team, but with whoever had explained the purpose of a sprint review to everyone. Clearly…they didn’t “get it”. And neither did the stakeholders, as they continued to politely chuckle at the jokes and applaud each teams’ efforts. It seemed as if the ceremony was simply there to check a box in the Scrum process list.
Never Again!
Needless to say, the teams never took quite this same approach again in their sprint reviews J. While I truly honor the notion of self-directed teams, I immediately laid out some guidelines and goals for our future sprint reviews.
Some of them aligned quite naturally with the Agile Manifesto, for example the notion of demonstrating working code at the end of each iteration or sprint. But some of the guidelines were unique to our organizational and cultural dynamics.
That’s actually the focus of this post…I want to share some of the guidelines, strategies, and the mindset we leveraged to turn-around our sprint reviews. Over time we move from:
- Polite applause ..to.. enthusiastic cheers and aha moments
- Polite applause ..to.. gaining congruent & constructive feedback
- Selling & marketing our results ..to.. making them transparently honest
- Small crowds ..to.. stand room only & video taping
- PowerPoints ..to.. working software whenever possible
- Entertainment ..to.. showing business value & exposing team effort
- Going through the motions ..to.. intentional and congruent feedback
- Selling and marketing our results ..to.. having them speak for themselves!
Surely it didn’t happen overnight and we continued to adjust and fine-tune our sprint reviews over time. However, we achieved a state in our reviews where they became the cornerstone for our agile adoption across the organization.
Let me share some of the things we focused towards…
Guidance towards “Excellent” Sprint Reviews
In general, I like to consider the sprint review as a “big deal”. Why? Because it is.
An agile team has spent a focused period of time, working on the most important stories on the planet, and is ready to deliver working software surrounding those features or stories. This stuff is hot off the presses and people should inherently care. They should be excited to see the results. Heck, you should have to beat them away at the doors.
It’s the teams responsibility to effectively REVEAL their efforts. And I’m not simply talking about the software. No, they should be telling & showing a story surrounding their work. It should contain context and narrative. There should be a connection to the last sprint and towards future sprints.
So below I want to share some critical focus points and a sample review agenda for your consideration. I hope the specific ideas help you to improve your reviews, more effectively engage your stakeholders, and create a more energetic reveal for your teams.
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—
Introduction
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
Close
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,
Bob.
BTW: a presentation of this material was shared at the 2012 Atlanta Scrum Gathering. You might find it interesting as it compliments this article.