One of the most significant activities within the Scrum framework is the Sprint Review, which is heavily reliant on the empirical pillars that underlie Scrum.
Stakeholders in a product can interact with the Scrum Team and the product increment that was developed during the Sprint at the Sprint Review event.
The outcome will be that the Scrum Team may build something that doesn’t provide customer value if the team is not completely transparent and sharing as much information as possible, or if the stakeholders are not fully engaged.
Objectivity in the Sprint Review
By developing a common understanding of what the team tried to accomplish, why they tried it, whether they succeeded, what the team will do next, and why transparency in the sprint review can be achieved.Learn more about in certified scrum master training from Universal agile.
Embracing the values of courage and openness, the team should be transparent and share both good and bad news. This will increase the likelihood that stakeholders will give the Scrum Team autonomy. Hiding anything might reduce stakeholders’ trust in the team, which might lead to micromanagement:
What is Sprint’s goal?
Giving the Development Team the “why” for the Sprint is what the Sprint Goal does. The Product Owner has a goal in mind for the Development Team to accomplish at the beginning of the Sprint. The next stage of the road map, which was decided upon during the previous Sprint Review, will typically be where this objective will come from. The objective and Sprint Goal should be slightly different from one another if the entire objective cannot be completed in the Sprint.
Therefore, the Sprint Goal and the percentage of the Road Map it fulfills should be communicated to the stakeholders. This should help the stakeholders understand the Development Team’s direction, the value it should provide, and whether the direction was in line with their expectations.
Was the Sprint Goal accomplished by the team?
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. Admitting this can sometimes take courage. Again, openness fosters confidence. Be prepared to explain why the Sprint Goal wasn’t delivered if the stakeholders ask why it wasn’t accomplished, as this is another likely scenario.
Which PBIs from the product backlog were included in the sprint?
The stakeholders should be fully aware of what the Scrum Team has produced because some of them will be responsible for it or, in some cases, responsible for paying the bill (if the team is working for an external client) (or attempting to deliver). This means that PBIs included in the stretch goal (those not addressed by the sprint goal) should also provide some value, and the stakeholders should be made aware of their existence and how they do so.
To increase transparency, it is occasionally beneficial to go over each PBI, including the Acceptance Criteria (ACS), so that stakeholders can inquire about each one and how it contributes to the achievement of the Sprint Goal, as well as how each of the stretch goal items contributes to value in the case of the latter.
The outcome of the most recent increment
The stakeholders should be made aware of what value has already been realized if the roadmap is designed to deliver a certain amount of value at specific milestones, or whether the increment is on track to deliver the anticipated value. This might affect what the stakeholder believes the team should deliver next because the roadmap might need to be adjusted.
What project is the team planning to build next, and why?
The stakeholders must be informed of what the team will be building next and why, so they can gauge the value they should be receiving, as part of the sprint review.
The three elements of empiricism
In empirical process control, a team frequently adjusts its priorities. The team has the resources necessary to reassess its objectives and tactics as it gains more expertise. But how is empiricism applied in actual life?
Transparency, inspection, and adaptation serve as the three fundamental pillars that support every application of empirical process control.
Transparency
Everyone involved can clearly understand their reality thanks to transparency. Without such knowledge, mistakes are made, strategies are poorly carried out, and unhappy customers result. For a development team, transparency enables everyone doing the work to accurately track their progress, quickly identify roadblocks, and make steady progress toward the sprint goal.
Scrum inspection
The term “inspector” or “auditor” in the context of Scrum refers to more than just one person. Since undesirable deviations can happen anytime, anywhere, every team member is expected to keep a close eye on the condition of their product, processes, and procedures.
The Sprint Retrospective, when the Scrum team internally evaluates issues that have occurred and decides something that can be improved for the next Sprint, is one of the best times to formalize this Scrum Team based inspection.
Adaptation
When an empirical process deviates unacceptably and it is determined that this deviation may result in an unacceptable result, it is used to highlight these areas through inspection. Adaptation can be used by a Scrum team to change direction.
An organization can embrace patterns of continuous growth and change by approaching every endeavor with the mindset that it is its mini-experiment, and by adjusting and improving its systems and processes in response to feedback.
Embedded scrum with three pillars
The built-in adherence of Scrum events and artifacts to the principles of transparency, inspection, and adaptation makes it easier for team members to consider the three pillars of empiricism in every complex thing they do. Every component of the Scrum framework—from planning to execution—incorporates the pillars to a deep degree.
Absent stakeholders
It is simple to understand why stakeholders view the review as useless if the Scrum Team spends a few sprints delivering infrastructure only rather than functionality or not giving a complete view of the sprint.
The ability of the stakeholders to evaluate the team’s output and the direction that the Scrum Team hopes to establish for the upcoming Sprint is what leads to inspection.
From the perspective of the empirical process, you can consider each Sprint as an experiment that aims to either deliver some value or pave the way for future incremental value delivery. The stakeholders can check whether they received the value they anticipated at the end of each sprint, and if not, the Scrum Team’s course can be changed.
The team needs to be as open and honest as possible with the stakeholders so that they can make informed decisions. If they believe the Scrum Team is hiding something, they may give the team less autonomy.
Empirical process control thrives in complex environments where predictability and cause-and-effect relationships are scarce, in contrast to defined process control systems that depend on a high degree of predictability of outcomes and distinct cause-and-effect relationships. This encourages practitioners to always expect the unexpected and provides them with the tools to manage it.
