The product sprint prospective review

How do you ensure that a product sprint ends well?

Erin Jo Richey
Known

--

At Known, we recently kicked off our latest sprint by facilitating a prospective review. Rather than wait until a project has failed, this design thinking-flavored activity was intended to give the team an opportunity to consider what might prevent us from finding sprint success and reaching our intended goals.

The prospective review was something that we led for a handful of companies working out of Matter Ventures. Every company is in a different place with their business and product, but each is following a loose cycle of 6-week sprints. Each has an overall goal that they’re working toward during the period, and at the end of the sprint the companies present their progress in a design review, in front of an audience of peers.

Why start your next sprint with a prospective review?

Product sprints work in part because they allow teams to flexibly evolve a product within the constraints of a certain time frame and scope. By starting our next 6-week sprint with a prospective review, company team members have the opportunity to come together and share thinking around the risks, challenges, and problems that might arise and prevent them from reaching their target. Where most learnings and takeaways for failed (and successful) projects happen at the conclusion, the prospective gives everyone an opportunity to look into the future, brainstorm possible outcomes, and discuss plans for preventing anything negative.

The prospective review also gives everyone a space to share their concerns and worries ahead of time, before they build up during the course of the sprint. The goal is to get everyone on the same page early on, thinking about the intended goal and preventing negative outcomes before they happen.

Setting up the prospective review

We rely on whiteboards, sticky notes, and timers for group exercises like these. Before the brainstorming starts, each team member should have a sticky note pad and a pen. The whiteboard can be divided into three sections for the exercise: a cell on the left for bad assumptions, a cell on the right for action plans, and a space along the bottom to prioritize assumptions.

The whiteboard layout during the prospective review

The overall sprint goal should be present and fresh in everyone’s mind. You may want to leave space at the top of the whiteboard to write it out. Or you could stick the sprint goal on an adjoining whiteboard.

Most of our teams had 2–5 people participating.

Brainstorming bad assumptions and blockers

The first step in the prospective involves listing out all of the things that might possibly go wrong and prevent the team from reaching the sprint goal. Ask your group, “What might go wrong?”, “How might this end poorly?”, or “What might prevent us from reaching our goal?”. Then give the team the opportunity to brainstorm and list out anything they come up with. This is where sticky notes become handy. As a teammate comes up with a bad assumption, they should share it with the group, write it on a note, and place it on the whiteboard.

Everyone writes their concerns on a sticky note

Bad assumptions (assumptions about what might go wrong or prevent the team from reaching the goal) can be internal and external. Considering some of these less desirable outcomes can be a bit of a downer, but you’ll resolve that during the third step. Sharing these negative possibilities early on helps everyone work together toward the objective — successfully achieving the goal of the product sprint.

Activity time: 10 minutes

Prioritizing the assumptions

The second step of the prospective review is to prioritize your assumptions on the whiteboard. As a team, you’ll want to discuss each thing listed and categorize it is high, medium, or low priority. Use the space at the bottom of the whiteboard to move sticky notes from the Bad Assumptions cell to a category under Priorities.

Move the sticky notes into categories based on priority

Discuss each concern briefly and make a quick decision based on its importance and likelihood of happening. Try not to get too tangled up as a team debating the priority of any one assumption. The end goal is to have a category of possible bad outcomes that are absolutely crucial to address and prevent.

Activity time: 5 minutes

Write out the action plans

In the final step of the prospective review, you’ll need to write out a quick action plan for preventing or dealing with your most pressing assumptions. During this stage, move each sticky note from the “high priority” class to the Action Plan cell on the whiteboard. As a team, discuss what can be done to prevent this possible bad outcome. Come up with a quick action plan, and write that down next to the sticky note.

Write an action plan next to each high priority sticky note

Bonus: If you want to expand upon this step further, before you write out the action plans you can order the sticky notes in the Action Plan cell. Depending on the nature of your sprint and the bad assumptions it might make sense to order them “most important to least important”, or you might aim for “most likely to happen first to likely to happen last”.

At the end of this step, everyone on the team should feel confident that the possible negative outcomes with the highest priority have been addressed with an action plan for prevention or recovery.

Activity time: 10 minutes

Wrapping up

Because we completed this exercise as a larger group, with multiple company teams going through the process all at once, we ended our session with 5 minutes for each team to reflect. People shared some of their most pressing bad assumptions and the strategies they were considering to prevent these during the new sprint.

For us, it was an opportunity to talk frankly as a team about some of the things that might prevent us from reaching our sprint goal in the next six weeks.

This exercise was inspired by the Gamestorming “Premortem” activity.

--

--

Erin Jo Richey
Known
Editor for

Information choreographer. User experience strategist. Co-founder of Known.