Goals are a good thing. Without setting goals, we have don’t know what we’re trying to accomplish and have no real way to measure success. They’re directive, motivating, and establish the guide rails around any activity.
In the world of Agile, every sprint has goals. These sprint goals make it clear to the entire team what the objective of each sprint is. They’re typically set by the product owner and delivery team, ensuring they’re both meeting the needs of the business while being simultaneously realistic when it comes to achieving them during a given sprint.
Ideally, there is only one goal per sprint. It creates a singular focus for everyone involved and prevents any conflicting priorities. Sprint goals aren’t effusive manifestos, either. They are a couple of sentences summing up the scope and purpose for that particular sprint.
The best sprint goals are SMART goals: Specific, Measurable, Attainable, Relevant, and Time-Based. The sprint will result in this essential thing being possible when we finish.
With a SMART sprint goal and its associated product backlog items in hand, the implementation team can get to work and keep their eye on the prize of meeting expectations. However, there’s some wiggle room concerning whether sprint goals should be completely reachable, or if there should be a bit of a stretch in their definition.
Sprint goal completion rate is a popular method of gauging an implementation team’s effectiveness. After all, the point of the sprint is to achieve the goal. So what better measure than how close they came to meeting it? Calculate this by determining the number of backlog items associated with the sprint goal completed during the sprint.
Why 100% Completion Isn’t the Best Target
With prioritization aligned and an agreed-upon goal established, you might think that the true measure of success is how often development teams are hitting their sprint goals. After all, the whole point of the sprint was to deliver against the sprint goal.
Yet, a 100% completion target can lead to a host of unintended consequences, thanks to Goodhart’s Law. In a nutshell, “when a measure becomes a target, it ceases to become a good measure.”
It’s human nature. If a reward is available (or you can avoid punishment), they will myopically focus on that target. They push aside the big picture and larger context as they concentrate on the measure. This focus dictates their value to the organization since that’s the company’s focus.
In an Agile setting, implementation teams will catch on pretty quickly that they’ll get better marks if they decrease the scope of each sprint. By “sandbagging” and inflating work estimates, they’ll buy themselves enough cushion to ensure they always get everything done.
It creates two negative factors for the organization. First, overall productivity will decrease. Sprints take on smaller and smaller goals as the teams push back against anything that might compromise their sprint goal completion scores.
Second, you’re training teams to put on blinders. They build what you’re asking them to build versus think more strategically about what they can accomplish. Not only will they squash any late additions to the sprint out of fear—they might not finish everything. They also won’t take a holistic view of the entire product and identify opportunities to address other goals, technical debt, bugs, etc.
Since that’s not what they’re being judged on, they have little incentive to do anything other than follow explicit instructions. And the pressure of hitting 100% every time removes the psychological safety net that might otherwise have encouraged them to speak up, get creative, and take more initiative.
Finding the Sweet Spot
The point here isn’t to denigrate the value of tracking sprint goal completion. It’s a worthy measure of how successful implementation teams are at accomplishing what they’re assigned, and especially useful for comparing different teams within the same organization.
But sprints aren’t the SATs or A.P. Chemistry. Because they’re not standardized tests of how good or bad a particular team is, it’s unfair and unwise to make this the primary measure of a team’s worth. More importantly, getting a perfect score doesn’t automatically mean they did the best possible job.
At ProductPlan, we measure sprint goal completion, but our target is 80% rather than 100%. Getting four-fifths of each goal completed on average gives us the confidence to plan accurately, but it removes the stressful pressure-cooker of always striving for 100% completion.
Being OK with sub-100% performance also means teams can receive goals that are a bit of a stretch. If the sprint’s going well, they have a little more to shoot for versus pretending they’re busy to avoid a more difficult goal.
Of course, companies can’t let their sprints fall too short of their goals regularly, because they’re not delivering enough value to the customers (or the organization) quickly enough. Once a team starts coming in below 70%, it’s time to get concerned and reevaluate things.
This assessment shouldn’t just be limited to the team’s work during the sprint itself. Leadership should also evaluate the accuracy of the level of effort estimations, the sprint scoping process, and product management expectations. Any or all could be contributing factors to a team’s flagging performance.
Tracking Sprint Goals
At ProductPlan, we track sprint goals at the individual team level—where each team has its own roadmap. After each release, the team notes its goal completion percentage.
Each team’s performance then rolls up to an organization-wide level. There, the Engineering heads track progress throughout the year to see if things are still on pace to hit the overall 80% goal.
It has a few benefits. First, an individual sprint that goes off the rails and falls significantly short of its goal is just one data point for both that team and the overall Engineering organization. If it’s truly an anomaly, it won’t have a major impact on the total performance measure.
By each team keeping its ongoing roadmap, there’s ample opportunity to gauge how that individual team is performing. It’s easy to spot if there are any concerning or encouraging trends. It’s also granular enough that an investigation into the performance can show causation for an aberration.
Then, with the overall rollup, leadership compare teams to their peers. If one team is doing poorly or another is excelling, leadership can identify root causes and address them, share best practices, or even reassign team members for better load balancing and resource optimization.
Creating a More Productive Environment
The quest for perfection often ends in failure, disappointment, and decreased morale. It leads to people gaming the system to avoid those harsh consequences. It’s human nature to minimize negative ramifications, even if it has undesirable long-term effects.
By acknowledging, embracing, and even slightly encouraging teams to shoot for “good enough” instead of “perfect,” they can produce more and better output. Instead of constant criticism, lowered expectations, or living in fear of failure, implementation teams, and the product organization can become true partners in shooting for value in a creative and supportive environment.
Don’t let one metric dictate how teams approach each sprint. Mainly when that metric is so subjective based on each sprint’s scope. Shooting for a “B” average in honors product development is far better than racking up “A plus” grades in remedial courses. Plus, it encourages far more collaboration and creativity.
