How the Sprint itself supports Adaptation - Back to the foundations of the Scrum framework (27)
Remember that Scrum is founded on empirical process control, and that adaptation is the third pillar, following transparency and inspection.
During each of the Scrum Events, and throughout the Sprint itself, the Scrum Team and the stakeholders adapt what they deem necessary in order to minimise any deviations to acceptable limits which they have identified during inspection.
Adaptation is making adjustments in order to minimise any deviations to acceptable limits concerning agreed goals.
So far I have covered the Sprint Planning, Daily Scrum, Sprint Retrospective and Sprint Review. What about the Sprint itself?
Note that each of the events is a formal opportunity to inspect and adapt.
This does immediately mean that during the entire Sprint itself there are informal moments to do that.
Therefore I expect that the adaptations we are performing during each of the events are also continued throughout the entire Sprint, as needed. So that, as a team, if we feel there are changes needed to address undesired variances, we can immediately take action.
From earlier blog posts you might remember that:
- during Sprint Planning you are looking at how to get closer to the Product Goal in the next Sprint,
- during the Daily Scrum you are looking at how to get closer to the Sprint Goal,
- during the Sprint Review you are looking at how to get closer to the Product Goal by looking at the current state of the Increment and looking further ahead in the Product Backlog,
- during the Sprint Retrospective you are looking at how to get closer to quality targets (Definition of Done) and to get closer to effectiveness goals.
These events take place at specific moments during the Sprint. If during the Sprint itself, outside any of the Scrum events, you and the team are detecting additional variances against any of the goals set, and these are of such importance that waiting for the next event would be too late, don’t hesitate, take action. Adapt as needed.
Outside the Scrum Events undesired variances do occur. Assess their importance fast enough to ensure the team agrees action can wait until the next corresponding Scrum Event, or if action needs to be taken sooner.
Together with your Scrum Team, evaluate your Sprint:
- When do you typically identify unexpected things, variances, isses? Is this mainly outside or during a Scrum Event?
- For those identified outside a Scrum Event, when do you evaluate their impact? Do you wait until the next appropriate Scrum Events, or do you do this as close as possible to the moment of identification?
- During your impact evaluation, do you take the outcome into account to determine when to take action? And does this show you that for some deviations you need to take action sooner than the next appropriate Scum Event is planned?
We hope you will find value in these short messages and if you are looking for more clarifications, feel free to take contact.
Next week we'll have a look at Adaptation and the Product Backlog.
If you want to take a deeper dive into the core concepts we are covering in this blog series, then surely check out our Professional Scrum Mastery workshop.
Don't want to miss any of these blog posts? Have the professional Scrum foundations series weekly in your mailbox.