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.
Let’s have a look at the Sprint Review.
In earlier articles in this series we already identified that during the Sprint Review transparency is created about progress towards the Product Goal. And that also Inspection to identify any unexpected deviations against this goal can be identified.
Based on these insight in progress towards the Product Goal, the team and stakeholders have a conversation about what would be useful to have (next) in the product to move closer towards the Product Goal. This important information should be reflected in the Product Backlog.
Some new Product Backlog Items might be needed, others might be lower ordered. Still others might need to change, or have become obsolete. Is the Product Goal as it stands even still desirable…?
Correct, during, or at least as a result of the Sprint Review , your Product Backlog is adapted. If during one Sprint Review this is not the case, this could happen, twice is strange, three times, then probably something in your Sprint Review is not as expected.
Two things out of experience I then question:
– Is the format inviting for the stakeholders to share their insights and feedback?
– Are the right stakeholders invited and present who can pass valuable feedback?
As the Product Owner manages the Product Backlog, he/she is accountable the necessary updates happen. This can be delegated to team members or he can do this himself.
But hey, this is changing the scope!? Maybe. Does it matter though? The Product Owner’s accountability is to maximise the value the team creates. If a change for this is needed in the Product Backlog, then so be it.
During the Sprint Review, the Scrum Team together with the stakeholders update the Product Backlog to reflect the expectations to achieve the Product Goal.
Together with your Scrum Team and stakeholders, evaluate your Sprint Review:
Do you discuss progress towards the Product Goal?
Does the Product Backlog reflect the expectations from the users and the market?
Is the Product Backlog showing all identified items to achieve the Product Goal, and is it updated as needed?
I hope you find value in these short posts and if you are looking for more clarifications, feel free to take contact.
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. We have some scheduled in the coming period.
Don’t want to miss any of these blog posts? Have the professional Scrum foundations series weekly in your mailbox.