Thank you for the detailed reply and more insight into the things that influenced your decisions 😃
For context on where I work and where my thinking comes from - currently I full time with a small team of 3 developers (myself included). Previously I've worked at larger companies with 100+ developers working on the same project at once so the last 6 months have been quiet the change. I also do a small amount of contract work on the side for clients.
Currently at work we're tackling the some of the same issues/goals you've mentioned:
Focus value of the feature to our business/end user
Deliver quality over quantity
Break it fast and deliver often
Our approach to achieve these goals has been to focus on breaking down our requirements into stories that are only the value-add/feature they provide and then create tasks within them, each feature as you said needs to be as 'atomic' as possible. We then point the feature with the effective 'cost' it will have on our team to complete it (based on rough time, complexity and risk).
We don't find that this process holds us back as it only consumes 2-3 hours every fortnight (~45 minutes planning on sprint start, and 2x 1 hour sessions on Wednesday's to discuss where we're at and what needs to come in to the backlog, be refined for next sprint and then pointing what we have 'certainty' on) and we are able to estimate reasonably effectively how much we'll be able to deliver each sprint.
So long as we remain focused on completing the tickets in the order we bought them into the sprint, we've found that we remain effective and keep delivering value quickly via our processes (and the CI improvements we've made in the last few months have enabled this further)
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
and these are bought up and discussed at every retrospective we've had.
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!
However, I still do not think that these new metrics you're deploying are any better than story points in themselves;
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)
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
frequency of deployment doesn't strike me as a measurable metric but that could just be the wording or my interpretation of it! 😉
I think there were other, far simpler and measurable ways to tackle the issues you mentioned than what you've described has been done.
I think I'd rephrase this now to say something more like; It would seem that you could continue to measure the things you want and get the metrics out by continuing to use story points - as they don't seem to have been the issue for you team(s) in my opinion. Rather, I believe that you could make small and incremental process changes through actions. Reading the agile manifesto thoroughly and applying it better than you admit that you have been - that may be more likely to provide you with the benefits and improvements you're looking for!
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.
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. 💯
Thank you for the detailed reply and more insight into the things that influenced your decisions 😃
For context on where I work and where my thinking comes from - currently I full time with a small team of 3 developers (myself included). Previously I've worked at larger companies with 100+ developers working on the same project at once so the last 6 months have been quiet the change. I also do a small amount of contract work on the side for clients.
Currently at work we're tackling the some of the same issues/goals you've mentioned:
Our approach to achieve these goals has been to focus on breaking down our requirements into stories that are only the value-add/feature they provide and then create tasks within them, each feature as you said needs to be as 'atomic' as possible. We then point the feature with the effective 'cost' it will have on our team to complete it (based on rough time, complexity and risk).
We don't find that this process holds us back as it only consumes 2-3 hours every fortnight (~45 minutes planning on sprint start, and 2x 1 hour sessions on Wednesday's to discuss where we're at and what needs to come in to the backlog, be refined for next sprint and then pointing what we have 'certainty' on) and we are able to estimate reasonably effectively how much we'll be able to deliver each sprint.
So long as we remain focused on completing the tickets in the order we bought them into the sprint, we've found that we remain effective and keep delivering value quickly via our processes (and the CI improvements we've made in the last few months have enabled this further)
While not official, if I were to write down our sprint health metrics they're probably along the lines of;
and these are bought up and discussed at every retrospective we've had.
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!
However, I still do not think that these new metrics you're deploying are any better than story points in themselves;
number of features deployedas the same metric asnumber 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)code qualitydoesn'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 qualityfrequency of deploymentdoesn't strike me as a measurable metric but that could just be the wording or my interpretation of it! 😉I think I'd rephrase this now to say something more like; It would seem that you could continue to measure the things you want and get the metrics out by continuing to use story points - as they don't seem to have been the issue for you team(s) in my opinion. Rather, I believe that you could make small and incremental process changes through actions. Reading the agile manifesto thoroughly and applying it better than you admit that you have been - that may be more likely to provide you with the benefits and improvements you're looking for!
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.
Hello again! :-)
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 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.
Yes! I totally agree with this one. :-)
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.
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. :-)
Thank you for your comment again! I appreciate your effort responding, and I've really learned from our feedback. 💯
Thank you for being open to discussing and receiving feedback - I've certainly been able to learn from your replies as well 👍
Do a follow up post in a few months - would love to know how it's getting on!
That’s a great idea! I’ll do it! 😁