Owning and maintaining a Product Backlog comes with quite some responsibility. If you are a Product Owner then 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.
It is Scrum Master’s responsibility 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 a common practice for a team to define one or two timeframes for refinement to take place, depending on the sprint length. In later versions of Agile
The metrics called Scope Change is trying to answer the question of 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
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 it 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). Transparency must be followed 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 would absolutely limit this expression to a team level. Also, let’s not forget, 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 mostly applies for sprints with duration less or equal to two weeks. The longer the sprint duration, the greater the chances for changes to happen and that reflects in the configurable thresholds. Inevitably occasional non-green events will happen but that will not affect the moving-window overall score for the Scope Change metric heavily.
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 areas of possible improvements.
Being amber and red for a prolonged periods of time is suggesting you should not use Scrum but Kanban instead, for example, or getting professional Scrum coaches on board.
Stay tuned for next stories about the Agile Tools!