January 18, 2022


News for Agilists

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

3 Pillars of Scrum (source https://medium.com/serious-scrum/empiricism-transparency-33adad8fbba2)

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)
Empirical Process Control in a nutshell. This process creates a closed-loop system, where new knowledge is fed back into the system.

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

Sprint Review

Source: https://www.quickscrum.com/Sprint-Review-Meeting

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.

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?

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.

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.

Source link