Measurable Sprint Goals?
Hi everyone,
my team is currently struggling with how to properly define our Sprint Goals. In Scrum Master Training, I learned that the team should do a forecast of the work it can achieve in the sprint. A sprint goal is then worked out by the Scrum Team, following which some PBIs that were forecasted for the sprint may be exchanged for PBIs which better match the Sprint Goal.
So far, so good... In practice however, we're having some difficulties. The most pressing of which is how to make the Sprint Goal measurable. As I understand it, in order to be an actual goal, there must be some criteria with which to evaluate whether or not the goal has been met at the end of the Sprint. For some time now, we've sort of picked the most important acceptance criteria of the PBIs that were forecasted and put them down. But in essence, that's only marginally better than defining the sprint goal as "finishing all the selected PBIs", which is exactly what we don't want as a sprint goal.
So, my question is this: How does a Scrum Team arrive at criteria it can use to inspect whether or not the Sprint Goal has been met at the end of the sprint? Do any of you have some real-life examples of good and measurable sprint goals?
Regards,
Julian
> As I understand it, in order to be an actual goal, there
> must be some criteria with which to evaluate whether
> or not the goal has been met at the end of the Sprint.
Not really, because by then it would be too late. There may very well be criteria which assert whether or not the delivered increment proves to be valuable, or an hypothesis which validates or invalidates an MVP, but that's a separate concern.
The Sprint Goal is a coherence which causes the Development Team to work together during the Sprint, rather than on separate initiatives such as individual items from the Sprint Backlog. It gives them joint purpose, and allows a forecast of work (the Sprint Backlog itself) to be framed and replanned if necessary. There's no requirement that the goal be measurable, though it should always be possible to determine if it is still useful and attainable. An example might be delivering a shopping cart function.
What has worked for me is to state a Sprint Goal as a generic statement about what the Scrum Team intends to accomplish in the next sprint. I avoid specifying any acceptance criteria around the sprint goal, as it only serves as a guide and a way for the team to identify with the purpose of their sprint work, as opposed to something they can check off as "met" or "done".
According to your post, you've experienced an issue when borrowing acceptance criteria from stories in the sprint for your sprint goal. What do you do then if one of those stories is moved out of the sprint? Is your Sprint Goal no longer achievable?
Keep your Sprint Goal limited to a single statement containing either a theme for the sprint stories or a business-value goal. Allow yourself the flexibility to meet the sprint goal in the event that one or more of the items selected are not completed by the team for whatever reason. Ask the question around the items selected "Why are we doing this?"
Some key words that may help you with your Sprint Goal statements: Improve, Increase, Expand, Allow, Continue, Add, Build, Create.
Good luck.
According to your post, you've experienced an issue when borrowing acceptance criteria from stories in the sprint for your sprint goal. What do you do then if one of those stories is moved out of the sprint? Is your Sprint Goal no longer achievable?
That was precisely our problem. It meant that there had to be some "fixed" stories that were absolutely non-negotiable w.r.t. the sprint goal. If those hadn't been done, the sprint would fail. And we realised this was a problem, but had no solution at hand.
Honestly, both Ian's and your advice surprised me. I didn't think generic statements could make good sprint goals. With a sprint goal such as (for example) "Improve the user control panel", how can we determine if we're actually meeting the sprint goal? Maybe I'm entirely on the wrong path here?
The Scrum Guide states that "A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed." It was my understanding that that inspection of the Increment included inspecting whether the sprint goal was met. Is that not the case?
The Scrum Guide also says that "The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.". I can certainly see how the sprint goals you describe provide guidance to the development team. But how is it an objective to be met?
Think of the Sprint Backlog as a forecast of the work needed to meet the Sprint Goal. Progress towards the goal can then be measured by means of burn-down charts or some other projective practice. The Sprint Goal is the coherence that lies in the selection of work. Beyond the progress towards it, a goal is not necessarily a discretely measurable property.
Julian,
I have had success thinking of a Sprint Goal statement as less of a destination, and more of a direction. Instead of saying "I want to lose 15 pounds", say "I want to lose weight". Same direction, but you aren't associating specific criteria to your goal.
You can have the same stories (exercise, eat healthy foods, eat smaller portions, avoid snacks, etc.), but you don't have to get into the weeds figuring out how those stories will result in a 15-lb weight loss. The theme is around "losing weight" (or "reducing technical debt", or "improving the customer online experience", etc.).
And if for whatever reason one of those stories isn't completed (I just couldn't get to the gym much), you can still assess throughout the sprint if you are on track to meet your Sprint Goal.
I want to thank you both for your valuable input.
I talked it over with my team and we'll try setting sprint goals in the way Timothy defines for a few sprints, see how that goes. After all, Scrum is also about experimentation ;-)