Introduction
If we are talking about sprints and sprint goals it is fair to assume use of the scrum framework. There are many good ways to build products, if you are not using Scrum, there may still be useful elements of this post for you.
Here are few examples of statements from the Scrum Guide about sprint goals.
Having set the Sprint Goal and selected the Product Backlog items for the Sprint, the Development Team decides how it will build this functionality into a "Done" product Increment during the Sprint.
During the Sprint, no changes are made that would endanger the Sprint Goal.
A Sprint would be cancelled if the Sprint Goal becomes obsolete
The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint
People personally commit to achieving the goals of the Scrum Team
Myth Busting
A common misunderstanding is that the mechanics of a sprint are built around delivering the sprint backlog. In reality a sprint is built around achieving a goal. The Sprint backlog is there to support achieving that goal.
It's achieving this shared team goal that makes Scrum a framework for collaboration, rather than a process.
In practice we often see teams committing to deliver everything on the sprint backlog, and that becomes the goal.
In sprint planning, the goal should be identified first before pulling in items into the sprint backlog. The reason we pull items into the sprint is that they are items that help us achieve the goal.
Teams commit to delivering the goal, not delivering the sprint backlog. If there is a better way to achieve the goal, Scrum teams are free to ignore what is written on items in the sprint backlog, or chop and change the sprint backlog to help them meet the goal more easily.
Why would we want sprint goals?
There are many benefits to sprints goals, here are just a few:
Outcome over output
Goals can represent valuable progress, releasing something important to our users, not solely focusing on productivity. Instead, building the right thing in the right way.
We should always focus on maximising the value and impact of what we do, simply delivering a certain number of stories or points should never be our objective, any such measures are a means to plan and forecast, not goals to be achieved.
Focus
We can organise our day to make the most effective progress we can towards the sprint goal and manage other distractions that divide efforts away from achieving it.
Teamwork
When we all share a goal, we can work together to achieve it. This is the essence of a team. If we are working on unrelated work the team will pull in many different directions, which can drive difficult team dynamics.
Creativity
We can find more creative ways to achieve the goal which might not be as we had originally planned. Perhaps we save some effort or improve maintainability, conversations happen that otherwise would not.
Commitment
It’s not motivating to churn through a backlog. People feel more committed to the cause of achieving an outcome than they do just completing items of work.
Planning
If we understand the goal, we can plan the right work that helps us achieve it, rather than just filling up available capacity.
Self-Organisation
With a clear, shared goal, we enable ourselves to grant autonomy to the team to figure out how to achieve that goal, removing the overhead of unnecessary team coordination.
When goals feel counter intuitive
Sprint goals are one of the most common things teams and organisations struggle with. They require us to work differently and a great deal of change can be required to enable that. It is not just about thinking up goals at sprint planning, we need the whole delivery system to be configured to enable goal setting by the time we get to planning.
Whether or not we are using goals effectively is a window into how well we have transitioned from the mindset of output to outcome.
If we are largely working as individuals on relatively unrelated items, sprints will not represent increments of valuable progress towards a vision.
If this is not addressed, the practice of goals is often dropped, or goals simply become items or a list of items from the backlog to deliver.
Collaborating towards a goal
Scrum teams collaborate to achieve goals. Many teams believe they collaborate but do not. They co-operate, but there is a big difference.
Consider a band making an album. If they wrote 3 songs each, they would be co-operating. They may achieve a goal of having 12 songs for an album, but would the album be any good? A great album is a piece of art played from beginning to end, not a collection of 12 unrelated songs.
Being too concerned with individual productivity will disable us from thinking in this way. We must think about the value the team is trying to add.
Shaping Product Backlogs
A good way to think about a product backlog is as an iceberg. Above the waterline we have sliced individual work items to do soon. This should be a small amount of the potential work on our backlog, i.e. the tip of the iceberg.
Beneath the waterline are ‘epics’ that we breakdown when we get closer to delivering them. Epics represent higher-level valuable steps we plan to take towards achieving our product vision.
This avoids backlogs becoming a dumping ground for ideas and requests, some we never end up doing. Instead, from the backlog we get a coherent visualisation of the value we intend to add soon, which have been broken down from a higher-level piece of value that we are trying to realise.
When our backlogs are shaped like this, we can quickly understand the wider purpose for what we are trying to achieve, and shape goals that help us iterate towards that.
We will not be able to create a backlog in this way unless we have started from a high-level vision of what we are trying to achieve with our product. Everything starts from there.
Planning ahead
Only inexperienced teams believe they only need to look ahead to the next sprint. For us to deliver on our product vision, we need an understanding of how we think we are going to get there. The difference to more traditional planning is that the level of detail in that plan is appropriate to the ‘planning horizon’ that we are working to. A plan for a sprint might be detailed, but a plan for the next month or two would be more high level.
Sprint goals feel intuitive when we have a high-level plan. If we consider the wider vision we are iterating towards, we can plan valuable steps to take us closer to achieving it.
Planning like this can also help greatly with backlog refinement as we can be refining the appropriate items that fit the next steps we want to take.
We then craft goals from a selection of items that we understand well already when we get to planning a sprint, enabling us to think about the goal rather than getting bogged down filling in missing acceptance criteria or estimates.
Finding valuable goals from any backlog
Even if our backlogs are not perfect, goals can still help us by bringing us back to valuable outcomes.
If we do have a long backlog of ‘stuff’ which hasn’t necessarily been broken down from valuable epics, instead of looking at prioritising our backlog purely based on the individual value of a work item, look for a group of work items that if done together, deliver value greater than the sum of the parts.
For example, one small piece of technical improvement by itself may only have a small amount of value, but if we had a number of improvements in the same area done together, the value added by that Sprint would be greater, even if some of those individual items would sit lower in a backlog when prioritised individually. Forming a goal around delivering that will feel much more intuitive.
Thinking Laterally
‘Delivering something’ is just one way to think about sprint goals. We could have goals around addressing a risk or testing an assumption. These are often good options early on in a wider delivery, as we look to drive down risk early.
With a team that is just starting out, we might want to set some goals around establishing some working practices, achieving some predictability, or making sure we carry out a practice properly this sprint, for example.
SMART Goals
The Smart acronym below is an age-old acronym for shaping goals, making sure goals fit the acronym.
· Specific (simple, sensible, significant).
· Measurable (meaningful, motivating).
· Achievable (agreed, attainable).
· Relevant (reasonable, realistic and resourced, results-based).
· Time bound (time-based, time limited, time/cost limited, timely, time-sensitive).
When thinking about what is achievable, it is important to think about what is inside and outside of a team’s control. Shaping a goal that had numerous dependencies would not be helpful. Try to iron out or have a plan for those dependencies first, so the goal can be met independently.
Example Sprint Goals
There's no one right way to write goals, but here are a few examples from my past experiences.
Deploy a simple first iteration of a user log in that forces existing users to authenticate their access the product when the ‘Force Users to Login’ feature switch is enabled. Have a selection of test accounts configured that can be used to demonstrate the feature.
We will log the success or failure of log in attempts and provide a summary of what we have learned from this data in the sprint review.
Release a feedback questionnaire that will be presented as an option at the end of the payment user journey and enable monitoring of how many users are opting to provide feedback, share any initial feedback responses in the sprint review.
Create a process to hard delete data older than 6 months and schedule this to run overnight with alerting should the process fail. The job will be proven in the test environment and operating successfully in production by the end of the sprint.
Build a proof of concept that will allow us to assess the relative ease in which we can integrate with the third party vendor and share learning with the team via a tech talk on dd/mm/yy
Sprint Goal Templates
Professional Scrum Trainer Steve Trapps suggests using this format as a template:
Our focus is on <Outcome>
We believe it delivers <Impact> to <Customer>
This will be confirmed when <Event happens>
He has a series of example of this template in use on his blog post here: https://www.scrum.org/resources/blog/sprint-goal-template
Kommentare