Hey there! So, picture this: I packed my bags and headed off to Germany, all set to sprinkle some Agile magic on a fintech company as their Agile coach. They were all about Scrum, but after diving into Agile and Lean methodologies, one of the teams decided to shake things up and go Kanban-style. It was a whole new world for me, and I’m here to share my lean metrics ride with you.
Workflow
First off, let’s talk workflow. We started with double statuses like “Ready for Peer Review” and “In Peer Review”. But then we thought, why not just push the ticket forward without assigning it to anyone? So, our workflow looked something like this:
Backlog -> In Qualification -> To Do -> In Development -> In Peer Review -> In Testing -> Ready for Deployment -> Done.
In this flow, developers would snag tickets from “To Do”, get cracking on them, and when they felt they were good to go, they’d toss them into “In Peer Review” without assigning them to anyone. Then they’d shoot a quick message in the team chat, saying, “Hey, this one’s ready for peer review!” and someone else would pick it up. Not the textbook way, but hey, it worked for us.
The Cycle Time
Now, let’s talk numbers. Cycle time, ever heard of it? It’s basically the time it takes for a ticket to move from “In Development” to “Done”. Simple, right? But here’s the kicker: some folks argue that we should subtract the time spent waiting for others from the cycle time. But hold up, waiting is still part of the process, even if it’s not the fun part. So, my take? Include the waiting time in your cycle time calculations. It’s all part of the game.
The Lead Time
And then there’s lead time. This one’s from the moment a ticket hits “To Do” till it’s waving goodbye from “Done”. Some folks start counting from the moment a ticket is born, but that just muddles things up. Lead time starts when you decide to tackle a task, plain and simple. Keep that to-do list short and sweet, and you’ll get a clearer picture of your lead time.
Estimation vs. Cycle Time
Now, let’s compare the above lean metrics. Estimation vs. Cycle Time, anyone? Here’s a fun fact: the size of the task doesn’t always affect how long it takes to get done. Crazy, right? Whether it’s a one-story point or an eight-story point ticket, the cycle time tends to stay pretty consistent. That’s why some folks swear by #NoEstimate. Sometimes, simpler is better.
No Estimation
Speaking of simpler, let’s talk again about No Estimation. It’s like estimation but without all the guesswork. Instead of slapping a number on a ticket, you break it down into bite-sized chunks. Sure, it’s not always perfect, but it sure does make life easier.
Throughput
And here’s a gem: throughput. It’s all about how much stuff your team gets done in a set amount of time. Forget about counting bugs, though. Just focus on the completed tasks. Trust me, it makes predicting future work a whole lot easier.
Other Lean Metrics
But wait, there’s more! We’ve got metrics galore: capacity, full capacity throughput, per-person throughput, you name it. These babies help you gauge your team’s efficiency and spot any hiccups in the workflow.
Capacity
This one’s important because it tells us how many people are actually available to work during a certain period. Imagine you’ve got a team of five full-time developers, but one of them decides to take a break for half of the iteration. Well, that means our capacity for that iteration drops to 90%. Things get even trickier when you’ve got developers with different capacity contracts like maybe someone’s only working at 60%. It’s like juggling, but with schedules!
Full capacity throughput
Now, this is a straightforward one. We measure our throughput based on the assumption that everyone’s working at 100% capacity. It gives us a clear picture of what we could achieve if all hands were on deck.
per-person throughput
Divide the full capacity throughput by the total number of developers in your team, and you’ve got this metric. For example, if our team churns out 10 tickets in total, and there are 5 of us, that’s 2 tickets per person. Why does this matter? Well, it helps management see how adding new members to the team affects our overall output. But, here’s the catch – whenever we add new folks, there’s usually a dip in throughput at first. It’s like adjusting to new teammates, but we usually bounce back eventually. However, if the team gets too big, that dip might just stick around forever.
Conclusion
Now, here’s the deal with metrics: they’re like puzzle pieces. Sure, one piece might not tell you much, but put ’em all together and you’ve got yourself a picture. And remember, these metrics are for your team’s eyes only. Share ’em wisely, and always keep the bigger picture in mind.
So there you have it, folks. Lean metrics that I normally use in a nutshell. Hope these tidbits help you streamline your workflow and boost your team’s productivity. Got any thoughts? Drop me a line!
Also, do not forget to check out my other post about 7 ways of defining Key Results that make your OKR successful