Is achievement of sprint goals an accurate measure of performance?
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?
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.
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.
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.
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.
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."