Posts Tagged ‘sprint review’

Is that even the right question?

Sprint Reviews: my experience is that they can swing from compulsory to optional and very often fall short of their true potential. Some teams see them as “demos” – a place to “show off” and prove that we did some work. Others see them as a place to give Stakeholders the reassurance that we are delivering against our plan and are on track. Sometimes, they can be a place for feedback: usually when our customer is external and it’s the only chance we get to show them something while it’s still in progress. I’ve seen organisations make them compulsory – but then only invite the team, and I’ve seen other organisations choose to do them quarterly, usually after a major feature has gone live, and then the team spends hours preparing for them. Usually, it’s a presentation. Rarely is it interactive or collaborative.

I was working on a team that frequently cancelled their sprint review. Arguments ranged from:

  • We’ve already shown the stories to the key subject matter experts (SMEs): they have given their feedback
  • It takes too long to prepare for it: we’ll show everything once we have the end-to-end journey completed (and often, released)
  • There was an Exco meeting already this sprint: we covered everything then. No need to repeat. Let’s just have a team review. (Side comment – if your Scrum team needs a meeting every sprint to show each other what happened in the sprint, then that’s a signal there are other problems to solve.)

Cancelling a sprint review made my Scrum Master heart very heavy. The Scrum Guide describes the Sprint Review as follows:

The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.

During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.

Some of these conversations WERE happening. But they weren’t happening in our Sprint Reviews nor were they happening with the whole team. These conversations also often focused on the roadmap from a feature-list perspective rather than how our product was evolving. Our sprint review had turned into a presentation – and one that required a lot of preparation – so it was no surprise that the team wasn’t seeing the value. We tried some experiments to get more interaction out of our attendees (often about 50 when everything shifted to virtual), without much success. Mostly they seemed to be there to get updates on how things might be progressing rather than out of interest in how our Product was developing.

So I took a step back. And decided to approach the problem with my facilitator hat on:

  • Who were our stakeholders? Why were they there?
  • What was the desired outcome of the Sprint Review – and were we inviting the right people?
  • What did the people we were inviting want out of our review?
  • Why did we seem to have multiple versions of the same meeting?

One clue to this problem was that my Product Owner and other key people in the management space often referred to the Sprint Review as a Business Review. Long story short, my first a-ha moment was this:

What was happening in our space was that the stakeholders for both meetings were pretty much the same people. And those people were not comfortable having project type debates in front of the team. And although they were interested in the thing we were building, it was at a high level and more in terms of progress rather than a desire to build the best thing for our users.

If you take these two types of interests, and then consider the following stakeholder analysis for the two “meetings”, you would get two different groups of people (with some overlap):

Another thing I noticed was that whereas the group of stakeholders for the project would remain fairly consistent; the group for the Product could shift sprint-to-sprint depending on what the sprint goal had been. Based on this observation, if your meeting invitees for your sprint reviews never change, then that might be another signal that your Sprint Review is not actually a Sprint Review.

I believe that in a true Product focused environment where decision making sits mostly in the team, the Sprint Review could and should satisfy both interests. However, while most organisations are still transforming and things like budgets, team composition, and ROI still sit with managers, it may be wise to use this perspective and ensure you’re having the right meetings, with the right people, on the right cadence for both needs to be satisfied.

What has your experience been with Sprint Reviews?

What a-ha moments have you had?

Review, review

Posted: March 12, 2014 in Scrum
Tags: ,

One of the Scrum ceremonies I’ve focused on across both my Scrum teams is the Sprint Review (review). The basic/common use of the review is to demonstrate stories completed as part of the sprint. One of my team members called it a ‘dog and pony show’. Typically it is poorly attended by anyone other than the team, has some live demonstrations (if you’re lucky), and a lot of Powerpoint slides.

Although demonstrating working software is a very important part of the Sprint Review, it is not the only part. A Sprint Review is also supposed to be an opportunity for various stakeholders to review what has happened during the sprint and adjust the product/project vision accordingly. The whole point of agile (and lean) is to continuously learn and improve – and a sprint review is where you apply your learning to what you are building (and not how you are building it – this happens in the Retrospective).

More succinctly:

The point of a Sprint Review is to inspect the increment and adapt the Product Backlog. It is a collaborative working session, not a presentation. The Sprint Review is designed so that all attendees can inspect what has just been done in the current Sprint and then work together to discuss what the next optimal move is for the business. This means discussing the Product Backlog as it currently stands.

ScrumSense suggested the following agenda for a review (which I find a useful starting point):

  • Review the sprint outcome against the sprint goal
  • Demonstrate the functionality delivered (done stories only)
  • Focus on:
    • functionality “fit for purpose”
    • how the product could be improved
  • Discuss any challenges
  • Highlight technical debt encountered or incurred
  • Highlight impact of external factors (interruptions, team members off sick, etc.)
  • Discuss impact of what was learnt on the current priorities (or vision) (i.e. reviewing the overall backlog)
  • Choose the next Sprint Goal

Re the last item, although I think it’s a good idea to discuss the next main focus, I find a better place to agree and firm up the sprint goal is at the end of Sprint Planning I.

The diagram below also illustrates the intention and process of the sprint review nicely:


It is important to stick to the rule around only demonstrating done stories, otherwise your team may find itself in a downward spiral where they have to show ‘started’ stories further and further in the future as their done stories have already been inspected in earlier reviews (while they were not yet done). Some people choose to cancel reviews when there are no done stories from the sprint. I think it does depend on the situation, but there is a con to having the team feel that they don’t really have to deliver anything at the end of their sprint, and it is also often helpful to use the time to discuss why stories were not done. Usually there is a good reason and an opportunity to garner support to remove that impediment in the future. It also increases visibility with your stakeholders and, in the case where activities external to the team may impact the product vision (e.g. customer market research), the overall product review is still valuable.

The other challenge is who to invite. The ideal response is “the whole world”, but with space and time constraints as they are in most organisations, this is not always possible. We tend to adapt our audience based on what we are working on at the time and agree who to invite during planning. If your users and stakeholders are the same people and are seeing stories as work progresses (ideal), then it may feel that there is not as much value in showing the completed stories again. Again, value may still be derived in considering the bigger picture. I think there are cases where reviews probably can be cancelled or held less frequently, but that should be the exception rather than the rule and a responsible team and Scrum Master will question the need to not hold a review at the start of every sprint (at least).