was your sprint successful?

2023-08-15

On my team, we care a lot less about whether we completed X tickets or Y points in a sprint. We care a lot more about whether or not we accomplished the critical sprint goals we agreed on at sprint kickoff.

It's not that we don't care about velocity or seeing all the tickets disappear from the board (that is a nice feeling), but it's meaningless to the business if all the points we completed were on tickets that ultimately didn't mature the product in the right direction.

At the beginning of each sprint, the team commits to two goals. In each standup, we discuss whether our progress toward each goal is red, yellow, or green and adjust our work accordingly.

But what makes a good goal?

Maybe an easier way to answer this question is: what is a bad goal?

A bad goal is:

Vague

This one is kind of obvious, but you shouldn't have goals like "make X better" or "improve Y". When will you know to claim these? Phrases like "make better", "improve", "increase", "decrease", etc are all red flags.

Not demonstrable

If you can't show something to someone to prove that you accomplished your goal, then it's not a good goal.

Not measurable

Examples are "improve the efficiency of X", "decrease the load time of Y", "increase adoption of Z", "add more to T". How will you know to declare success? Is a 1% improvement good enough? Should we add the extra task into the sprint to get from 30% to 40%? Be conservative if you have to, but declare an actual, measurable number to set a success threshold.

Too technical for a non-engineer (PM, designer, manager, etc) to understand

In my experience, no matter how technical the team is, there is still "non-engineery" way of describing your goal. Ok, you want your goal to be "change the indexing scheme of X table to SP-GIST". That's fair that you want to do that, but why are you doing that to begin with? Isn't it to "improve the efficiency of X query by Y%"? Make that your goal instead.

Passing the buck to another team in order to claim pseudo-success

This one is one is tricky, and I've seen a lot of teams fall into this trap. Bad goals in this category are thigs like "get our side of X done". To be fair, there are times this makes sense. Maybe in your organization one team is frontend and one team is backend. Getting the frontend done of some feature could be a good goal for the frontend team. However, if your team is full-stack like mine, be careful about goals like this. Yes, your goal might be risky/gated on another team's work to get done, but if you don't make it baked into the goal, your team will not be incentivized to help the other team get their work done, or speak up to motivate them.