Owning and maintaining a Product Backlog comes with quite some responsibility. If you are a Product Owner, you are familiar with day-to-day decisions about the content and the order of the work. Which User Story is more valuable for the customer is often in conflict with the engineering team’s view on the priorities and how a (software) system is architected and coded.
Scrum Master’s responsibility is to make sure the work flows smoothly from ideas to the development members of the product team. The term development is meant in its broadest meaning – not just coders but also UX, design, QA, QC, and others needed to create a potentially releasable increment. The responsibility comes from educating, coaching, facilitating Scrum events, and proper usage of the (digital) tools, to name a few.
The two Scrum events in which most prioritization is executed by (re)ordering Product Backlog Items (PBI) are Sprint Planning and Backlog Refinement. The latter is formally not an event but an ongoing process. It is common for a team to define one or two timeframes for refinement, depending on the sprint length. There will be sprint events templates in later versions of Agile Tools to choose from or have guidance from them. This will be covered in later posts.
The metric called Scope Change is trying to answer how good a team is at prioritizing PBIs. I use this term interchangeably with User Stories in this post. Product Owner decides on priorities based on input from all stakeholders and possibly the same data or evidence, if you are familiar with the Evidence-based Management book and EBM Guide. The development/engineering team is one of those inputs.
Looking at the example chart below, you can quickly observe the non-green bars telling us that some undesirable events have occurred. Staying in the subjective limits of agility in Scrum, the metric can be presented with two thresholds – one for the amber and one for the red zones. The chart will come preconfigured, but it will be available to configure per organization and per team. What I meant by subjective limits is the second and the third pillar of Scrum: inspection and adaptation. You should use them consistently, and some digital guidance we can offer can be helpful.
You will be able to take a note, to have a record of the reason why such an event happened (not yet in early Beta). We must follow transparency on every step, and if it takes you a minute or two to have the data at hand and ready for smart insights on how to improve the outcomes, then the tooling can improve your business results.
To generate the Scope Change chart, you will have to provide three input values:
The total number of Story Points the team forecasted
The sum of Story Points added during the sprint
The sum of Story Points removed during the sprint
We still use the term Commit internally. Maybe old habits die hard, but I would limit this expression to a team level. Also, let’s not forget the commitment to achieving the goals is one of Scrum’s five values.
Why would you add User Stories during the sprint, which would result in the bar-raising up, or why would you remove them, which would result in the opposite effect? One explanation is poor planning, and that primarily applies to sprints with a duration less or equal to two weeks. The longer the sprint duration, the greater the chances of changes, reflected in the configurable thresholds. Inevitably, occasional non-green events will happen, but that will not heavily affect the moving-window overall Scope Change metric score.
So little data to gather and so much insight generated! Together with other metrics, this one will contribute to the team and the company to guide you on possible improvements.
Being amber and red for prolonged periods suggests you should not use Scrum but Kanban instead, for example, or get professional Scrum coaches on board.
Stay tuned for the subsequent stories about the Agile Tools!
Update: In early 2022, a product reboot has happened, which pivoted the product much more towards setting goals (OKRs) but still has its roots in teamwork, metrics, and evidence-based management.