Scrum Project Release Goals

By Mark C. Layton

Each release plan has an overall business goal associated with it, called a release goal. This goal is created by the product owner, and ties in directly to the product end goal, which is the product’s vision statement. The release goal establishes the mid‐term boundary around specific functionality that will be released to customers to use in the real world.

Having an explicit release goal expedites the prioritization process: If a requirement doesn’t align with the goal, you don’t have to worry about that requirement in this release. Any given requirement should earn the right of your investment. Leave it tucked away in the product backlog until it can support a priority goal.

Think of the three layers of goal setting as a prioritization filter system. The vision statement is the highest boundary. If a feature doesn’t fit the overall vision, it isn’t for this project. Don’t even let that requirement on the product backlog. The requestor needs to go get funding for that idea separately — don’t be a stowaway on my project.

Next comes the release goal. This is the mid-term boundary. If a requirement doesn’t fit this goal, it stays in the product backlog. And finally, the shortest-term boundary is the sprint goal.

Goals drive the product backlog and the release plan, not the other way around. Every feature and requirement must be thought of in terms of “does it fit the goal.” This is purpose driven development. Goals drive what makes the product backlog. Goals drive what gets included in a release. And goals drive what gets included in each sprint.