Skip to main content

Is achievement of sprint goals an accurate measure of performance?

Last post 07:52 pm March 16, 2023 by Ben Safratowich
5 replies
06:32 am March 8, 2023

Recently, I was working at a company that was quite early in their agile journey. At a sprint review, a 'manager' from outside the team stood up and said 'if you haven't achieved your goals, the sprint is a failure'. I can think of lots of reasons why this isn't true:

 - The team could have delivered useful software, but not quite everything in the goal.

 - The team could have hit an unexpected roadblock, and haven't learnt valuable things about how to progress.

 - The goals may have been very ambitious to start with.

If management measure the team based on whether the goal was hit, this will create a risk-averse culture where 

1: sprint goals are not ambitious

2: effort is wasted estimating that could be spent doing

3: teams are rewarded for the accuracy of their estimates instead of the value of their output.

 

So this week I decided to do a practice test for the Professional Agile Leader certification, and was surprised that the statement 'Consistent achievement of Sprint Goals is a good indication that a Scrum Team is performing well.' Is considered true. I would argue that 'Consistently delivering value to users' is a good indication of performance, and 'consistently achieving sprint goals' is a sign that the culture still needs to evolve. 

Does anyone have some insights for me?


09:31 pm March 8, 2023

Scrum is about learning to build the right thing at the right time. The consistent achievement of Sprint Goals is a good indication of such progress.

What that external "manager" may not have entirely grasped is that, for validated learning to work, a Sprint ought to be a safe to fail environment.


09:46 pm March 8, 2023

It seems like the manager is confusing "goal" (an aim or desired result) with something more like a "commitment" (an obligation). Although a team is committed to making the goal the central focus of their Sprint, the goal is not an obligation that the team has to achieve and you've identified some major factors that lead to a team not achieving their goal.

For me, the question about how often the team should achieve their goal is a function of how risk averse the organization is. If we consider predictability to be how often the team achieves their stated goal, then an organization that is extremely risk averse will want high predictability and the team will be more likely to craft less ambitious goals that they are highly confident in. Other organizations may be more tolerant of risk and unpredictability, so crafting ambitious goals and maybe failing the goal while still delivering one or more useful Increments could be acceptable.

I will raise one point of caution with ambitious goals. Don't forget that a sustainable pace is a key principle of agility. If your highly ambitious goals are driving the team to work at a pace that is not sustainable for the long term, it may be time to scale back on the goals for a while. You may not need highly ambitious goals Sprint-over-Sprint. It could also be good for morale (and maybe stakeholder relationships) if you consider the implications of going into multiple Sprint Reviews without achieving the full goal you set out to achieve.

I don't think that the culture needs to change in either case. There's nothing wrong with being risk averse and desiring predictability, just like there's nothing wrong with ambitious goals that may not come to fruition.


12:55 pm March 12, 2023

The crux of the issue is: "The Sprint Goal is defined during the Sprint Planning by the Scrum Team."

It sounds like management or the PO is setting the sprint goal.  The scrum team needs to help define and agree to the sprint goal.  It drives decisions during the sprint, but needs to be agreed to.  Management can't say "thou shalt finish this feature this sprint".

Yes, the sprint goal is very important but so is velocity.  I use the sprint goal to make sure we are making the right decision during the sprint.  Velocity helps to see how well the team is working together to accomplish things when the sprint is over.  Both are important.

When you mention the possibility of creating a risk-averse culture, that's a real red flag.  That tells me the company is not adopting the true meaning of agile.  Working together, flexibly, to deliver working software.


07:41 pm March 14, 2023

The only way to consistently reach (somewhat ambitious) goals is to perform well. So yes, persistent achievement is an indicator of performance. It doesn’t measure performance, though. Development performance can’t really be measured. Except for the number of bugs, maybe.

As for the manager’s statement: Choice of words aside, not reaching a goal is a failure. In a positive environment, the team would discuss how that happened, define improvements, and move on.


07:52 pm March 16, 2023

Regarding the 'manager' claiming the sprint a failure if the sprint goal isn't achieved, I agree with all of your statements on why this isn't true.  As the company was early in their Agile journey it's understandable how a stakeholder may confuse the sprint goal with a waterfall style milestone or gate, assuming that's what the company was moving away from.  In that case it would be a good opportunity for the Scrum Master to serve the organization by coaching stakeholders that completing the Sprint Goal is secondary to "creating a valuable, useful Increment every Sprint."  This could also be backed up by the first listed Agile Manifesto Principle, which states, "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."  


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.