Scrum contains three Artefects each of which have a corresponding Commitment. It took me quite a long time to get my head around these so I will attempt to explain what both of these terms mean here.
| Artefact | Commitment |
|---|---|
| Product Backlog | Product Goal |
| Sprint Backlog | Sprint Goal |
| Increment | Defintition of Done |
But what exactly are Artefacts and Commitments? The 2020 Scrum Guide explains that
Scrum’s artifacts represent work or value
and
Each artifact contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured…
…These commitments exist to reinforce empiricism and the Scrum values for the Scrum Team and their stakeholders.
To show this I’m going to describe how these apply to the Product Backlog and its corresponding Commitment the Product Goal. Then, in over the next two weeks I’ll cover the Sprint Backlog, Sprint Goal, Increment, and Defintion of Done.
The Scrum Guide tells us that the Product Backlog (the artefact) represents Work (or value), it is an ordered list of all the work the team intends to do to deliver value to it’s stakeholders. The Product Backlog Items (sometimes written in the form of User Stories) are often sized to give an indication of how much effort is required to deliver them and to help the team with forecasting.
The Commitment contains the information to create transparency to stakeholders so they understand what to expect as the work is delivered. In the case of the Product Goal this is a medium term future state which the scrum team is working to deliver. It describes a set of functionality the team can use to plan against and create a focus beyond the Sprint by Sprint goals.
The scrum team can assess what’s delivered each sprint and look at the work required to meet the Product Goal. They can then decide the next work which needs to be delivered and begin to plan it. This is commonly done in the Sprint Review and Spring Planning sessions. In fact, when a team is following Scrum diligently there is often a lot of crossover between these two sessions with one flowing seemlessly into the next.
I’m having quite a lot of fun talking about Product Backlogs and Product Goals in Donuts and Dragons, the book I’m currently writing about Agile Doftware Development. Initially the team focus on improving overall user experience, then they realise that they need to pivot and adjust their Product Goal accordingly.
It’s worth noting that
[The Scrum Team] must fulfill (or abandon) one objective before taking on the next.
The Scrum Guide 2020
This is to prevent the team splitting their focus and attempting to deliver multiple projects at once. Obviously something which wants to avoided.
Once the Product Goal is met (or abandoned in favour of a more appropriate one if required) the Product Owner will work with the team to identify the next goal. It’s not uncommon to see a high correlation between Sprint Goals and “Releases” in more traditional organisations. While planning a single deployment from release is far from recommended it often helps businesses to group work together into Releases or Projects (I know, all dirty words in Scrum) and the team can map the Product Goals onto these. After all, what is a Product Goal if not a collection of work to be done to deliver value to stakeholders and transparency to the business?
I hope this post has been helpful, next week I’ll discuss the Sprint Backlog and it’s Commitment the Sprint Goal.
dotdotdev.com 