Discussion on: Why we ditched story points to be more value-oriented

Hello again! :-)

While not official, if I were to write down our sprint health metrics they're probably along the lines of;

did we complete what we set out to do (committed vs completed) regardless of how much was completed
did any work items increase/decrease in scope (aka; was it pointed over/under) and why, how can we avoid that in the future
did we deliver value to the business and our end-users with what we completed

For me, those are pretty reasonable goals. The only difference in our approach is we want to have two simple main goals (delivery more and with more quality), and only the last one you said is in our top list. We also take care of the other goals you wrote, but what I want is to simplify our primary goals.

I think the best way to sum up how I'm thinking after reading your reply is that I think we both (and probably everyone else in the industry too!) are tackling the same issues and trying to find solutions to them - and I really appreciate reading other posts about people going through the same/similar things and trying different ways to solve them!

I think we share many metrics and approaches, what I wanted to clarify with this post is we tried to change our primary goals and metrics, so we improve the company direction. It wasn't bad, but focusing on delivery and shipping made us more product-oriented. I'm not saying the other metrics are wrong. I say the other metrics fulfill other goals that are less important for us right now.

I just see number of features deployed as the same metric as number of points completed - in the end they'll be about the same. Because if you do more features you'll see an increase in the number just like if you complete more points you'll see an increase (and vice versa)

Yes! I totally agree with this one. :-)

code quality doesn't add value to the customer directly (they only care whether they get x feature or not this week) and from what I've learned in the past I'd say that its notorious for being an arguably, poor indicator of software quality

I got into my trap here! 😁 Because what I can say with the indicators we have (We use Codacy for it) is estimate if we're going to spend more or less time on something and what is the health of the code (less healthy, more risk and uncertainty), but it's NOT a delivery metric.

I agree with you again.

frequency of deployment doesn't strike me as a measurable metric but that could just be the wording or my interpretation of it!

It's true, but It says what's the delivery health, if we want to have 'atomic' features and iterate fast we need to deploy fast, and many times. It says something of the project and delivery, although I have to say we're still thinking on what metrics we want to focus on here.

What we're doing right now is following more the shippable features that don't go back approach rather than checking all these metrics. Still, in the following months, we need to have a good overview of what's happening regarding our features and delivery, that's for sure. :-)

However, something I omitted in my original reply and removed before hitting submit was that I'll be the first to admit that I don't work within your organisation and I don't know the complexities or other challenges your teams face day to day. You all need to do whats best for you and as long as you (and your teams) can learn from any mistakes, make changes and continually improve - eventually you'll find what works right for y'all.

Thank you for your comment again! I appreciate your effort responding, and I've really learned from our feedback. 💯