All agile teams building software do it every day. The time might vary. Ours is at 9.45am. Some do it just before lunch, others at the end of the day but if you’re working in an agile team, it’s likely that you have a daily stand-up.
As an estimate, I think I’ve attended over 1000 daily stand-up meetings over the past 5 years. With all the agile teams I’ve worked with in this time I’ve noticed that the quality of these stand-ups has varied.
The stand-up meetings I have attended more often than not resolve around the answers to three questions:
- What did I do yesterday?
- What will I do today?
- What obstacles are impeding my progress?
Using these questions, everyone on the team gets an update on the progress of the project. The team celebrate notable achievements and uncover blockers to progress. Discussions continue after the stand-up using the information uncovered.
These questions differ a little from those described in the the scrum guide:
- What did I do yesterday that helped the Development Team meet the Sprint Goal?
- What will I do today to help the Development Team meet the Sprint Goal?
- Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
These more descriptive questions differ to the more simplistic ones that some teams have fallen back to using. The main difference is that all these questions refer to a “Sprint Goal”. This goal is the bearing for the iteration, giving the team something to aim for with their work.
Without this reference, stand-ups meander through the valley of self-reflection. Team members report progress on things which aren’t related to the sprint. The stand-up starts to turn into a general status update meeting. It starts to contain noise which is not relevant to the sprint. From the stand-up it becomes hard to know whether the team and sprint is on track.
Of course, all this is only possible if the team have defined a “Sprint Goal”. If you don’t have a bearing, how do you know whether you’re moving in the right direction?
Having effective stand-ups thus depends on holding great planning and sprint kick-off sessions. So, to make this work, it helps if you can plan an iteration around a theme and then turn this theme into a “sprint goal”. Defining the sprint goal at this stage will help you to have better stand-ups and keep the focus throughout the sprint.
The single themed sprint can also help to shape the way the team write code. When coding, it’s easy to get caught up in the implementation and lose sight of the reason for making a change. You fall down the rabbit hole. With a sprint goal, the team now has the ability to ask the following question:
Is the change I am about to make moving us towards the Sprint Goal?
If you can’t say the code you’re about to write is moving you towards the goal then should you be making that change?
It’s never quite as black and white as this but it’s something to consider. Teams I’ve worked with have used this tool to fend off story creep where stories never seem to end.
Defining a sprint goal can also help you at the end of the sprint. As part of your demo, it gives you a clear message to your stakeholders of what the team achieved or what they were trying to achieve. When the team has completed the sprint goal stakeholders can accept the stories and you can consider the sprint closed. The sprint goal for the next iteration can set expectations for the next batch of work.
Finally, the sprint goal can set some context for the retrospective. It can help the team introspect and identify areas for improvement.
Sprint goals aren’t a silver bullet, but they will help to focus the way the team works. They set the direction, and provide a useful marker and reference point for the team throughout the sprint.
So now you’re sold on creating sprint goals, how do create great sprint goals?
As with all goals, the best ones are SMART - Specific, Measurable, Achievable, Relevant and Time-bounded.
Fort more agile teams the sprint is a fixed length, so that’s the time-bounded part taken care of, but how about the rest?
A good sprint goal should be specific in the thing that you’re trying to achieve. It should detail what you want to do, without leaving space for ambiguity.
Let’s take an example of a sprint goal of “improve homepage performance”. To make this goal specific you might change it to “improve loading time of homepage including all assets”.
Next, you need to set the boundaries of success for this goal, making it measurable. Looking at our performance goal, we might add measurements to the goal to give it more focus. The goal could change to “improve loading time of homepage and all assets to under 250ms”. The addition of the measure (250ms) will give us a clear sign at the end of the iteration whether the team has met this goal.
Good sprint goals should be achievable. The responsibility of determining whether it is falls on team. During the planning session, the team should look at the details of the goal and use this to determine it’s viability.
Extending our example, is a loading time of under 250ms achievable in a single iteration? Of course, that depends on many factors. For example, what’s the loading time now? Do we know where the bottle-necks are? Do we know how to solve them?
Committing to a sprint goal that’s not achievable in one iteration will affect the way the team works. Just as bad is defining a sprint goal which the team has low confidence of achieving. The viability of the goal combined with the confidence of the team will determine whether the team meets the goal.
When planning, it becomes clear that the ability for a team to achieve a goal relates to the velocity and capacity of that team. You might need to revisit the goal when you’ve had chance look at the stories, and adjust the scope of what you’re trying to achieve.
Finally, the goal should be realistic. 250ms seems a reasonable loading time for a webpage, setting this at 2ms might not be as realistic. Once again, it’s about targeting success. Setting unrealistic sprint goals erodes trust. Trust between the members of the team, and the trust of the stakeholders in the team.
In all this, the key thing to remember is like the commitment, the sprint goal is the determined by the team.
Product owners and other stakeholders will try and shape the specifics and measurements for success for a goal. Yet, whether a goal is achievable and realistic relies on knowledge from the people on task for making it happen.
Sprint goals are an important and sometimes overlooked part of the agile development process. Taking the time to develop, agree and commit to sprint goal will repay itself throughout the iteration.
More importantly, they set the direction for a team. Everyone has a single simple question that they can use to check there bearings, and ensure we’re all going in the same direction.
Is this moving us towards our sprint goal?
