Last week I talked about what Artefacts and Commitments are and described the Product Backlog and Product Goal. This week I’m going to continue this theme but focus instead of the Sprint Backlog and Sprint Goal.
The Product Backlog is an ordered list of all the work which would deliver value to the product, we consolodate a future vision of this around a Product Goal. Within a Sprint we look at this at a much smaller scale, breaking down a single step the team aims to achieve and then comes up with a plan to deliver it.
Many teams I’ve worked with come at this the wrong way around. They look at the next work on the Product Backlog and through estimation and historical velocities select a number of stories which will “fill the sprint” usually carrying over anything which wasn’t completed in the previous sprint. Then they declare a Sprint Goal which is usually sounds like “Complete these Backlog Items” or “Do this, this, and this.” If you haven’t already I hightly recomment Jasper Alblas’ blog post about Sprint Goals.
Instead a team should look at their Product Goal and declare a Sprint Goal which will move them towards it. They should then identify the appropriate Product Backlog Items required to deliver that Sprint Goal and use estimation to ensure that it is realistic.
The Scrum Guide tells us that:
The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).
The Scrum Guide 2020
In other words once we have a Sprint Goal in mind we should identify the work required to deliver it (the what) and create a plan for how to deliver it (the how). With these three components in place we are in a position to start delivering.
As the Sprint progresses we should update the Sprint Backlog to reflect the progress of the work being delivered. PBIs may be marked as done or we may encounter impedements. However, by using the Daily Scrum sessions and the Sprint Backlog we’ve created enough transparency for us to be able to inspect and ensure that we are still able to meet our commitment – the Sprint Goal.
This is why a transparent Sprint Backlog is so important, it’s also why Daily Scrums are so vital. They give a daily opportunity to see issues and resolve problems so that the Sprint Goal is met. As soon as the team identifies that their Sprint Goal is at risk, perhaps the original approach won’t work or the effort required is greater than they originally intended they can adapt their plan.
Directly from the Scrum Guide
If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.
The Scrum Guide 2020
In other words the team should attempt to meet their Sprint Goal in a different way, perhaps by negotiating scope or taking a different approach. If the Product Goal is simply “do the work” then there’s no way the scope can be renegociated and the team will not make a move forward against the larger Product Goal.
Finally, if something happens which renders the Sprint Goal obsolete, perhaps a significant new piece of information, business incident, or realising that it’s impossible the Product Owner has the authority to cancel the Sprint and replan a new Sprint Goal.
I hope that this has given some insight into why the Spring Backlog and the Sprint Goal are so important. Next week I’ll progress on and we’ll look at the Increment and it’s Commitment The Defintion of Done.
dotdotdev.com 