Setting Sprint Goals

Setting Sprint Goals

My DevDiv counterpart, Chris Flaat, recently had a post on their Sprint 5 Planning.  He ends the post with a discussion on goal setting for a sprint.  This is a topic that we've struggled with in our teams' Scrum planning, so it’s time to write about our expereinces.

We’ve tried a few different things, from very granular goals to a more loosely defined ‘theme’ for the sprint.  While each approach has its pluses and minuses, both have worked well at times.  Thinking about it, I realized that the type of goal was highly dependent on the type of sprint that we were in.   I will classify our sprints into three different categories.

An exploratory sprint is one where the main goal of the sprint is to learn.  This is more common early in a release cycle.  Keeping with the Scrum focus on working code, the primary deliverable is usually one or more prototypes.  The goal will be loosely defined, for example, "Prototype the integration of product A with product B".  The team will collaborate closely with the Product Owner to navigate to the best possible completion of this goal.

An execution sprint is typical of work within a release that has been fairly well planned out in advance.  The goals for the sprint align with feature deliverables for the release.  The backlog for the sprint will be pulled off the release backlog for the team.  In this case, the goals will be well defined, granular, and lend themselves more easily to metrics collection.

A stabilization sprint happens at the end of the release.  The Test team is working to close down the release through functional and integration testing.  The Development team is primarily bug fixing.  In this type of sprint, the Test team will likely have well defined milestone goals just like in an Execution Sprint.  The Development team's goal will be to drive the bug count down to an internal or release wide target.  A good tool for this is using a Bug Burndown chart.

As you can see, we are not particularly agile in some areas of our process.  Overall, the MBF team has been using the traditional Microsoft milestone approach, typically a 6-9 month period with planning, execution, and stabilization phases.  We do implement feature by feature as you would expect in iterative development and all disciplines are active in all sprints. But as the sprint types imply, the early sprints are more discovery oriented and the later sprints are more stabilization oriented.

We are working to shorten up these milestones and become more agile overall.  It’s still likely that sprints with the characteristics of the types described will exist, but hopefully to a lesser degree.

In summary, it makes sense to align the granularity of your goals with the type of sprint that you are working in.