Mastering Empirical Process Control — Sprint Review

The Sprint Review is one of the most important events in the Scrum framework, and one highly dependent on Scrum’s underlying empirical pillars.

Empiricism in a nutshell

Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk. Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.
– The Scrum Guide

Let me guide you through how these 3 pillars are critical to each Scrum event, and how they can help guide you through the unknowns.

You can sum up the empiricism into:

• Have access to knowledge and a shared understanding (transparency)
• Trying something out based on that knowledge and view the outcome (inspection)
• Based on the results — which is new knowledge — try something else (adaptation).

With this in mind, how would we apply this to our Sprint Review?

Sprint Review

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint.
– The Scrum Guide

The Sprint Review event is where a product’s stakeholders can get involved with the Scrum Team and the product increment which has been built during the Sprint.

Without the team being completely transparent and sharing as much information as possible, or the stakeholders not being completely engaged, the outcome will be the Scrum Team potentially building something which doesn’t deliver customer value.

Transparency in the Sprint Review

Transparency in the Sprint Review happens by creating a shared understanding of what the team attempted to do, why they attempted to do this, whether they achieved it, and what the next direction will be and why.

Transparency builds trust — if the team are transparent and share both good and bad news (embracing the values of courage and openness), stakeholders are more likely to allow the Scrum Team to operate autonomously. Hiding anything would potentially degrade stakeholder’s trust in the team and this may result in micromanagement:

1. What was the Sprint Goal for the Sprint?
   The Sprint Goal provides the Development Team with the “why” for the Sprint. At the start of the Sprint, the Product Owner has an objective in mind, which he would like the Development Team to meet. This objective generally will come from the next stage in the road map, which was agreed on the last Sprint Review. If the entire objective can be met in the Sprint, then the objective and the Sprint Goal are the same, if not, then the Sprint Goal should be a slight variation of the objective.
   Thus, the stakeholders should be made aware of the Sprint Goal and how much of the road map this fulfils. This should give the stakeholders and understanding of what direction was set of the Development Team, what value it should deliver, and also if the direction set was what they were expecting.
2. Did the team deliver the Sprint Goal?
   This can sometimes require courage to admit, but you should always be incredibly transparent about whether or not the team was able to meet the Sprint goal and, if not, what impact this will have on the timescales. Again, transparency builds trust. There’s also going to be a reasonable chance that the stakeholders will want to know why the Sprint Goal wasn’t delivered — so be ready to explain this.
3. Which Product Backlog Items (PBIs) were taken into the sprint?
   As some of the stakeholders will be accountable for what the Scrum Team is delivering, or in some cases paying the bill (if the team is delivering for an external customer), the stakeholders should have full visibility of what the team has delivered (or attempted to deliver). This means PBIs in the stretch goal (those not covered by the Sprint Goal) should also deliver some value, and the stakeholders should be given an understanding of what they are and how they deliver value.
   For additional transparency, it is sometimes worth going through each PBI including the Acceptance Criteria (ACs), so that stakeholders can ask questions about each one and how they accomplish the Sprint Goal — and in the case of the stretch goal items, they can ask how each of these deliver value.
4. Sharing the Product Increment (aka The Demo)
   The most famous part of the Sprint Review — the increment demo. This is the part where the stakeholders can actually see the functioning software and/or other deliverables from the Scrum Team. The Scrum Team can either demonstrate the output for each PBI or demo everything in a single take. Naturally, this is where the stakeholders can have a much better understanding of what has been delivered, and this makes it much easier to feed into anything which they feel is missing (e.g. the common occurrences of “can you please change that text”, “You’re missing an error when some data is missing” etc…).
5. Results of the last increment
   If the roadmap is set up to deliver an amount of value at certain milestones, then the stakeholders should be given visibility of what value has been realised already, or if the increment is on its way to delivering the projected value. This may have an impact on what the stakeholder think the team should be delivering next, as the roadmap may need to be tweaked.
6. What are the team thinking about building next, and why?
   The final part of the Sprint Review is letting the stakeholders know what the team will be building next and why, so they can understand what value they should be receiving.

Absent stakeholders

As you can imagine, having missing or disengaged stakeholders is going to potentially result in “that’s not what I asked for” or “where is the thing I thought I was getting” much further down the line. One way to avoid this is the deliver vertical slices of functionality so that the stakeholders can see something end to end.

If the Scrum Team spend a couple of sprints only delivering infrastructure instead of functionality, or not providing a full view of the sprint (the items above), it’s easy to see why stakeholders see the review as pointless.

Inspection comes from the stakeholders being able to inspect what the team has produced, and what direction the Scrum Team is wanting to set next Sprint:

• Sharing the Product Increment — Demoing the product to the stakeholders and (maybe) letting them play with it. Was it what they thought it would be?
• What is the team thinking about building next — Why do the team think this is the best direction to go in? What value does it deliver to the customer?
• What the resulting benefits of previous increments are — Did the previous increments have the effect the stakeholders were hoping? (customer retention, customer increase, revenue increase etc…)

Adaption comes from allowing the stakeholders to feed into the direction of the team

• Product Increment — Maybe they want to expand the scope of what was built, maybe they were not happy with what was built and they want some changes (e.g. “can you please change that text”, “You’re missing an error code when some data is missing” etc…). This is where the Product Backlog can be adapted, as stakeholders request changes to the new functionality.
• Direction of the team — Are the stakeholders happy with the direction set by the Product Owner? Do they want to change direction due to changes in the market or because the benefits of the increments weren’t/can’t be realised.

From an empirical process point of view, you can think of each Sprint as an experiment, to hopefully deliver an amount of value, or create a path to delivering an incremental amount of value. Each sprint the stakeholders can ask the question, “did I get the value I thought I was going to get”, and if not, the direction of the Scrum Team can be changed (adaptation).

It’s important the team is as transparent as possible with the stakeholders; not only do they need to make informed choices but if they think the Scrum Team are hiding things, this may result in less autonomy.

That’s it for the second article of Mastering Empirical Process Control. I hope you found it useful. Please stay tuned for Part III in this series: how empirical process control pillars are keys to success at your Sprint Retrospective event.