Menu

2e1ax_default_entry_Screen-Shot-2014-03-25-at-20.08.08Of all of the meetings that an Agile team performs, the ‘demo’, ‘showcase’ or ‘show and tell’ at the end of each Sprint is the one that is least discussed and the one that you tend to see the least written about. There seems to be a widely held implicit assumption that it is the simplest of the meetings to conduct – much more straightforward than Sprint Planning, the Daily Standup or the Retrospective for instance.

I think this assumption leads people to underestimate and misunderstand the importance of the meeting. It is not just a demo, showcase or show and tell. It is meant to be the ‘inspect and adapt’ meeting for the Product and the Product Backlog. Its proper name in Scrum is the ‘Sprint Review’ but perhaps a better name for it would be the ‘Product Review’.

For the most agile teams and organisations, the Sprint Review means that traditional meetings such Projects Boards, Steering Groups and Change Boards are no longer needed.  Such meetings are rarely effective in decision making because they are too far removed form the actual work. They introduce delays as the team waits for decisions to be made, and they make poor decisions as they do not have great visibility of the true facts at play.

In an agile organisation the key decision-makers and stakeholders will attend the Sprint Review meeting at the end of each Sprint. The meeting will help them to understand the true state of the work and progress to date. They will use that information to make real decisions about the plan going forward in real time at the meeting. These decisions can then be put into effect on the very next day in the very next Sprint.

At its best the Sprint Review meeting is a major enabler of agility. At its worst it is nothing more than an opportunity for anyone with a passing interest in the product to waste an hour or two in a meeting without contributing anything at all, with no feedback gathered from real stakeholders and with no meaningful decisions made.

So how should a Sprint Review be run?

A Sprint Review should be held at the end of each Sprint to inspect the Product Increment and, if required, adapt the Product Backlog. The Sprint Review meeting should be timeboxed to 1 hour for each week of the Sprint. The Scrum Team and stakeholders collaborate to understand what happened in the Sprint, what changes occurred and what might be done next. The Sprint Review is an informal meeting, the intention of which is to create transparency, feedback and collaboration.

Within the Sprint Review meeting:

  • The Product Owner identifies what has been “Done” and what has not been “Done”
  • The Development Team describes how the Sprint went: what went well, what problems it had, and how it addressed them (they will hold a Sprint Retrospective following this meeting to agree how they can work more effectively in the next Sprint)
  • The Product Increment is demonstrated, questions about it are fielded by the Scrum Team and any potential new Product Backlog Items are identified
  • The Product Owner leads a review of the Product Backlog, drawing attention to any changes since the last Sprint Review
  • The Product Owner presents projected completion dates based on progress to date and everyone in the meeting collaborates to determine if the Product Backlog should be changed and what to do next

In Conclusion

Like many things agile, doing effective Sprint Reviews is difficult. Like many things in agile, the success of the Sprint Review depends upon the will and the courage of those in leadership positions to do things differently. It requires a different, agile approach to Governance, and a level of transparency and empowerment that can be a challenge for many organisations. With external suppliers, organisational politics and other factors at play an ‘agile-by-the-book’ Sprint Review may be out of the question, but any organisation that claims to be on an agile journey should be continuously looking at their Sprint Reviews and asking how they can make them more effective in promoting transparency, inspection and adaptation.