Sprint Goals

  4 minute read  

Sprint goals are the main facility that Engineering teams use to communicate their commitments and deliverable value to the rest of the business. Spring goals are drafted before each sprint starts and should be confirmed and prioritised with Product at sprint planning and/or kick-off.

How to write Sprint Goals

A sprint goal’s purpose is to communicate the value that the team has delivered that sprint to the wider business. This means that each goal should be:

  1. Written with the least amount of technical jargon possible. It should be understandable by any member of the business, not just engineers.
  2. Objectively measurable.
  3. Demonstrate the value of the work, or contain enough information that the value is apparent.
  4. Contain references to any supporting metrics or tracking (for example, relevant GitLab issue or epic).

Sprint best practice

Sprint goals do not represent all of the work that a team completes during a sprint, only the Product value. It is understood (and reported during retro) that teams are occupied with support, tech debt, planning and self-development tasks as well. These commitments are managed outside of sprint goals, and monitored during retros.

Number of sprint goals

It is tempting to itemise as many tasks within a sprint to highlight where the team’s labour was applied. This is not good practice. Ideally, a team should commit to no more than 3 sprint goals.

Sprint goals should focus only on the Product value that is delivered. If other responsibilities (bugs, support, etc.) have prevented the team from meeting its sprint goals, these issues should be raised in retro and discussed or accommodated for during planning.

If the team is working on a body of work that is not releasable during a sprint period (for example, far too large, or dependant on external factors) then the sprint goals should be written to focus on the portions of delivery that the team achieves - the technical breakdown is completed, the first section is merged, etc..

Carryover

In the case that a sprint goal is not met during the sprint, it should carry over into the next sprint. Whenever this happens, an explanation for the failed goal should be explored and documented during retro, and provided to Product during the following Sprint Planning or Kickoff when goals are being confirmed.

Sprint Goal Examples

Bad 1

  • (Bug#123) Deleting existing form design twice times out

This is a bug, it is not deliverable value. Don’t include it in sprint goals

Bad 2

  • Complete Establishment mandatory requirements

Doesn’t explain the value of this work. Add a link to the epic, where the work and value is explained

  • Complete Establishment mandatory requirements &123

Bad 3

  • Improve the UI on Tenant Settings

This is not objective or measurable. Rewrite to

  • Release new Tenant Settings UI to production &123

Less Bad 1

  • Create migration for new postgres trigger for audit log tables &123

This does not communicate value, nor is it easily understood. Rewrite the goal using simpler terms, and link to the epic for details

  • All database changes are logged and available for superusers to search and filter &123

Less Bad 2

  • New work rights UI &123

Doesn’t well clarify the state of delivery, the definition of done will be assumed. Define the exact state instead

  • Release new work rights UI to production &123
  • New work rights UI merged &123

Less Bad 3

  • Complete 12 weight of new ADP Integration &123

Issue weight is relative to the team and not well suited for communicating progress to the business. Instead, focus on the deliverable portion of the epic

  • New ADP integration module is bootstrapped and deployable from GitLab &123

Good 1

  • Complete technical breakdown session for Audit Log &123

If the next step in delivering a new feature or enhancement is to figure out exactly how to build it, make that your sprint goal. These tasks are time consuming and important to communicate to the business.

Good 2

  • Port Tenant Settings page to SPA with new filter and sort &123

This communicates the delivered change, as well as the additional value to the product. Worth noting, we don’t need to remove all technical jargon. In cases where all stakeholders have a clear understanding of a term (for example, SPA) it’s fine to use them. It’s worthwhile to check the understanding of terms during Sprint Kick-off.

Good 3

  • ~“priority::high” Performance Report Direct Reports MVP merged &123

Gold Standard!

This communicates the new feature to be delivered, links to deeper details, includes the scope level and definition of done as well as a priority badge to indicate the order than the team will focus on the goals.