Scrum answered: Sprint Review

Next episode of Scrum answered series is dedicated to Sprint Review.

We do not have anything to show on the Sprint Review – can we just skip it?

That’s a very common question, especially when the team faced multiple problems and challenges during the Sprint or they just focused on more technical things which are hard to present. The answer is really simple though – no, you must not skip the Sprint Review.

Why so strict? There are multiple reasons:

• Sprint Review is the only event that makes stakeholders be actively involved in team’s work. Use this occasion to receive feedback, discuss market situation and future development opportunities.
• It has to be done regularly in order to sustain stakeholders’ interest in what the team is doing, Sprint reviews need to be organised on a regular basis and cannot be cancelled in the very last moment. Think of board members or other VIPs of your company – would they treat you seriously if you cancel the meeting, which in fact serves the team, shortly before it’s due to happen?
• Sprint Review serves transparency. Treat yourself and your stakeholders well and inform what was delivered, even if not much. Share info on challenges / blockers the team had – maybe someone will help you solve them or minimize their impact?
• Finally, remember that Sprint Review is not only a demo, as some team members might think.  You should use this time to reflect on what to do next – what if due to low team performance next sprint priorities will be changed? (and you wouldn’t have known that without the meeting…)

Summing up, skipping Sprint Review means breaking the product feedback loop – basically it extends at least twice the time needed to receive feedback from stakeholders or users. This in turn increases product risk that you will deliver functionalities which are not needed and so won’t be used.

Can we present not-Done things during the Sprint Review?

It is not an easy question. In theory no, but I really like the practical approach (see Blog Manifesto), so my answer is… yes, you can show not-Done things during the Sprint Review, as long as you clearly explain those are not meeting the Definition of Done yet and that you present them in order to gather early feedback and discuss plans for further development.

Why so? Because you shorten feedback loop and allow the team to improve functionalities still in development, which is always faster, cheaper and more effective than fixing and making changes to the already finished development. At the same time you need to keep up transparency of what is Done and what is not-Done.

The truth is that we are used to the fact that work not finished in current Sprint will be continued in the next one.

Many teams start their planning by calculating how much capacity they need to finish leftovers and how many new items they can take. But that’s the wrong way of thinking. Leftovers should go back to the backlog (see also to re-estimate or not to re-estimate) and be prioritized together with all other backlog items. It can happen that changed market conditions, organizational changes or just feedback received from users will impact Product Backlog that way, that leftovers won’t be included in the next Sprint.

Transparent discussion about not-Done Sprint stuff during the Sprint Review helps to make such conscious decisions.

Sprint Review replaces the steering committee meeting, is that right?

Yes, in the sense that Sprint Review is the right time to ask questions like:

• When will this feature be probably finished?
• When will we be ready with the upgrade package?
• What was delivered in the last Sprint?
• What problems did you face?

No, because Sprint Review is an informal workshop rather than the status meeting. During this workshop stakeholders should get their answers on ‘status like’ questions and should also be involved into discussion of what we should do next and which features are the most valuable right now, according to market situation and surrounding environment. So, you can even say that also stakeholders should answer ‘status like’ questions asked by the Scrum Team, e.g.:

• How much are we planning to invest into the Product?
• Are there any changes on the market?
• When will be the best time to release our new package?

As you can see then, Sprint Review partially replaces traditional steering committee meeting.

In projects where only one Scrum Team is involved, Sprint Review + Retrospective should be enough to fully replace steerco.

In bigger projects some additional meetings and synchronization may be needed.

Who is responsible for the Sprint Review?

Product Owner is owning Sprint Review event, but it is the whole Scrum Team’s effort to do it properly.

• Scrum Master facilitates the event if needed and makes sure that everyone understands its purpose.
• Product Owner explains Product Backlog, describes Product Vision and leads discussion on plans for the future.
• Development Team presents the working software (Done Increment), explaining what was delivered in the last Sprint and responding to all questions about the product.

You should always remember that Sprint Review is not only for the Scrum Team but also for stakeholders and end users of the product. They should come equally prepared, ready to share information about budget, marketplace environment, competitors or actual usages of the product.

Can we make a Sprint Review joint with another team?

Yes, in some environments it is a great idea, especially when multiple teams work on the same product. Why so:

• It’s easier for stakeholders to have a joint product increment presented, rather than have it shown separately from different teams. This allows a better ‘big picture’ view to all.
• When presenting, discussing next sprint scope and future product plans together, teams have better chance to spot dependencies that could influence their velocity.
• Practically looking, it will also be easier to engage all stakeholders and users when you invite them to one longer meeting instead of two or more shorter ones.

Just remember about one crucial thing – having multiple teams organising a joint Sprint Review, you need to extend the event time accordingly.  The more teams you have, the more extra time should be added.

You could also consider a mixed formula, and after presentations of work done are finished by all teams, divide Sprint Review participants into smaller groups. Some stakeholders or users might be more interested in specific areas of the product which are linked to their area of expertise, and so may want to spend more time with just one of the teams. If you do not take that fact into consideration, you might face a problem described in the next question.

Stakeholders do not want to participate in the Sprint Review. What to do?

First you should try to answer one short question: Why?

In most of the cases people do not attend meetings, workshops or events they are invited to because they do not see any value in them.

In such case, where your Sprint Review is perceived as waste of time and a boring meeting, other activities get easily prioritised higher over it.  

That’s the sad true – I saw many boring, ‘status like’ Sprint Reviews and I wasn’t surprised by a very low level of attendance. There is no silver bullet on how to run a great Sprint Review, because depending on a product, project or even stage of the development Sprint Review can address different needs. Below you can find some hints and ideas on the Sprint Review formats. They all try to respond to one question which you should ask before selecting a format that would best suit your team: what the team needs to get from this particular Sprint Review?

• Change and experiment with format, as often as you can. Gather feedback from the team and from stakeholders and adapt to it.
• Try to engage as many people from the Development Team as you can.
• Rotate people responsible for preparation of Sprint Review.
• Instead of team member clicking through the new functionality, invite stakeholders to this (but remember you need to stay there and guide if needed!)
• Show as much system as you can and no more pptx than you really need to.

So far, most of the time I was able to avoid differentiating between product and project. But now I would like to share an idea particularly about projects. For this purpose, please consider product as an endless development and project as a timebox (fixed number of Sprints) implementation. Now, when you lead a project your Sprint Review should constantly change.

• During few first Sprint Reviews you should focus on the ‘show’ part – so presenting what was delivered and what the Team has achieved, even if not too much. Why so? Because of two things – you need to build trust and motivation. First, Stakeholders need to trust that the team is capable to deliver the project, and second, the Team needs to clearly see they are progressing and the job they are doing is considered useful.
• Focus on gathering users’ feedback when you are close to the production release. This is time when you have covered most of end-to-end processes and there is no need to focus on what was achieved during the last Sprint. Way more important is to give to users an end-to-end experience, receive their opinions and spot opportunities for last improvements.

In short, project’s Sprint Review should transform from the ‘show’ to more ‘workshop’ mode with time.

One of the formats I really like to use to help people focus on workshop part is a fair format – create multiple stands dedicated to particular groups of users (like for example system administrator, business user, supervisor) and invite them. On each stand they should have possibility to experience system and try to go through various business process and task. Remember not to leave users on their own, but to assure each stand is supported by a team representative ready to answer questions or present new functionalities, or just stand aside and observe users in action. This can provide you with huge feedback about the system which can be used while planning work for next Sprints.

Should you have any other questions about Sprint Review, feel free to ask leaving a comment. Stay tuned for the next Scrum topic.