Riffing Off the Agile Manifesto: Measuring Impact over Counting Story Points
Preamble
You can read the preamble here. This provides context around this series of articles.
Articles In Series
Riffing Off the Agile Manifesto: Preamble
Riffing Off the Agile Manifesto: Investing over Budgeting
Riffing Off the Agile Manifesto: Measuring Impact over Counting Story Points - You Are Here
Measuring Impact over Counting Story Points
What if it’s not about how fast or how much we deliver - but whether anyone cares what we’re delivering?
What would need to be true for us to care more about what we’re delivering than how fast we can deliver it?
The idea of celebrating how many points we delivered is interesting. What happens if we shift to celebrating how many of those points made a positive impact. This also means celebrating how many of those points were wrong. Simply assuming that getting more done equates to getting more impact is just not always true. Using points in the context of this article because well, for some reason they are persistent, and for a lot of people either something they like to use or something they can not escape.
Let’s take this idea of story points and try to use them to tell the story of our products and the impact the way we are working has on our products and on the validators (customers/users) we claim to care about delivering value for.
Measure Wrongness
How Many Points Were Wrong?
What might happen if we discovered we didn’t understand our validators (customers/users)?
What would have to be true for us to talk about the causes behind making the decisions we make?
Teams often talk about, or are forced to talk about, their velocity and how many things they got done. Yes, this is still happening. And this is typically still talked about in story points. It goes something like this:
“We need to improve our velocity.” Well, what does that mean? It needs to improve how? We need to increase the velocity? Ok, all 2’s are now 5’s. Problem solved.
Or
“Our velocity is great, we are getting 31 story points done each sprint.”
In all of these conversations we are equating getting more things done with creating more impact.
The question “How many points were wrong?” is something we can measure provided we think about it.
And wrong could mean features nobody wants or uses, solutions that don’t solve real problems, work that should get thrown away but doesn’t, rework, or things that create more problems than they solve.
“Ok dude, what do we do with that?”
Consider using this to learn about the system we work in or to stop bad ideas. This requires a deeper understanding of the decisions we make and what influences those decisions. It demands that we go even beyond thinking about our need to make better decisions faster.
Perhaps it’s time we rethink the way we make decisions.
Validated Valuable
Lets not pull things into “in progress” before we understand how we are going to validate it. Yes, this is a nice subtle change that anyone can do. Beyond just not starting something new before we validate is saying lets not put anything in the backlog without first validating the thing we just did.
What is the cost of value adding work waiting in a backlog?
Slow down, spend time talking with the validators who are using the product.
I once heard the dude talk about how language matters and he referred to customers and users as validators. I like that.
Understand how it is working, what it is solving, the impact it is having, and then make a decision about what’s NEXT. Don’t let NOW end so quickly. Stay in the NOW until it makes sense to talk about the NEXT.
LATER, well LATER is LATER.
-more on this in a future article perhaps-
References
[1] Hussman, D. 2012, “Dude’s Law”, Shinkle, C., Video Source Site Reference
https://www.nuagility.com/glossary/dude's-law