Tag: Sprint Goal

The Sprint Backlog and Sprint Goal

~ Adam ~ Leave a comment

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 Sprint Backlog should be a plan to achieve a Sprint Goal. The Sprint Goal should not be to complete a Sprint Backlog. Photo by olia danilevich on Pexels.com

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.

Daily Scrum

~ Adam ~ 1 Comment

Last week we talked about the Sprint Planning session, today I’m going to move on to one of my favourite scrum events. The Daily Scrum.

The fifteen minutes each day where the team catch up are some of hte most powerful, but also some of the most woefully misunderstood of all the scrum events.

The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.

The Scrum Guide 2020

In other words the entire purpose of those 15 minutes is to review the team’s progress against the Sprint Goal and ensure that they are still on track. They should consider progress, any new information they’ve discovered, and any risks they’ve found and discuss if any change of strategy is required to hit the Sprint Goal.

The Daily Scrum is about verifying progress against the Sprint Goal. Photo by cottonbro on Pexels.com

The Scrum Guide also says

The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work.

The Scrum Guide 2020

However, more than in almost any other event I see zombie scrum going on in Daily Scrums. In team after team, company after company I see teams standing up around a screen answering the dreaded three questions “What Did I Do Yesterday?”, “What Am I Doing Today?” and “Do I have any Impedements?” (by the way – 99% of the time people apparently don’t).

While there’s nothing wrong with this approach there’s something seriously amiss if the team do not circle back to address the main point of the meeting. Given the raw data we’ve captured from the team on their progress and their blockers do we still believe we are capable of meeting the Sprint Goal? Has something someone has said put that in jeopardy and what can the team do adapt.

The Daily Scrum is the daily iteration of the inspect and adapt pillars of empiriscm (which only works if there is a feeling of safety in the team which creates transparency). Instead of simply waiting for their turn to write the three questions developers should be listening to each other’s answers and looking for indication that the team may not meet it’s objectives.

Don’t be afraid to mix up the Daily Scrum format, but do be very nervous if you’re not discussing the Sprint Goal in each and every meeting!

Sprint Planning

~ Adam ~ 1 Comment

Last week we talked about the Sprint. This week we’re going to kick off with Sprint Planning. The Scrum Guide defines Sprint Planning as

Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team.

The Scrum Guide 2020

It recommends you do this by answering three questions. How is this sprint valuable? What can be done this sprint? How will the work get done?

In my experience most scrum teams by estimating Product Backlog Items, or PBIs (often called User Stories) and estimating how much work they can deliver by looking at their historical velocities.

This, in my opinion is wrong.

When teams do this it’s very easy for them to let the work drive the goals instead of the other way around. Rather than identifying what they want to achieve and working out how to deliver it they look at lots of granular pieces of work and cram as many into the sprint as possible, often losing synergy and coherence in the future.

It is always better for a team to look at what they want to achieve and what the various people can do to make that happen than to try and assign particular tasks to each person. This sometimes means that people’s capacity isn’t 100% utilised. But that time is infested in collaborating, learning, paying down tech debt, and supporting their team mates who are on the critical path. Far better than having everyone so stressed by an arbitrary deadline because some random user story was included in a sprint.

Working out what to include, or not include in a sprint is never easy

A team should always identify the next step forward for their product, the one which would yield the most value and plan the work required to meet that goal. They can use estimates to assess whether a particular plan for doing it is feasible. They shouldn’t focus on trying to fill up a quota of story points from estimates of varying accuracy.

It’s the PBIs which are planned to meet the sprint goal which we will use to verify our progress in the Daily Scrum sessions. This will be the subject of next week’s post so make sure you’re following the blog if you want to read it!