Sprint reviews: five steps to perfection with Herogami

A rather common misstep for Agile “beginners” it to lead sprint reviews by relying on team members’ personal opinions and bias when discussing what went well, and what not, at the end of each sprint. Sprint reviews can become completely irrelevant experiences when teams do not stick to data and actual facts, in particular in the context of Kaizen, aka when trying to assess what can be done better. 

Project progress and continuos improvement or Kaizen do not need your opinions and feelings: they need facts and hard data. As scrum master, you want to drive your sprint reviews skipping opinions and leveraging instead data and actual facts. 


Here's a recipe for the perfect sprint review by using Herogami.

1. Powerpoint Herogami Lighboxes

At sprint completion you want to visually summarize the sprint content in a very compact fashion. The typical Kanban column-split view may not be space-efficient, to avoid wasting projector space select View / Lightbox in your Issues or Stories View menu. In case there’s too many cards to see at once, group them to minify the cards.

2. Demonstrate the actual working product

Show the working product increment to the Product Owner and everyone else who is interested. The meeting should feature a live demonstration, not a report.

3. Visualize “done” with Herogami colored cards

After the demonstration, the Product Owner declares which items he now considers done. For example, a software item that is merely “code complete” is considered not done, because untested software isn’t shippable. Incomplete items are returned to the Backlog as candidates for future Sprints. In the Lightbox view, Herogami automatically mark any “in-progress” item with a color tag to support a better visual understanding of this process.

4. Leverage Herogami’s Wiki as the project blog

Create a new wiki type for your project and call it “project blog” and regularly enter comments and notes about the project progress, team feelings or contingencies. Review the project blog with your peers and stakeholders to recall specific episodes.

5. Record every sprint review in the Herogami Wiki

Herogami already provides a built-in wiki type called “sprint review”. Create a wiki article and set its type accordingly. Having the sprint review report in Herogami will help you keep a history of your projects’ reviews close to their planning.

As a final note, please remember that sprint review meetings are appropriate not only for team members to attend but also for external stakeholders and even end users. It is possibly the best opportunity to inspect and adapt the product as it grows from its embryo and progressively refine everyone’s understanding of the requirements. 

New products, particularly software products, may be hard to visualize on written documents and drawings. The majority of the end users need to be able to see a piece of functioning software to discover what they actually want. At your next sprint review meeting make sure you bring them on board.

Grumpy Herogami, Architect

28 Mar 2017