Episode 8 – Sizing the elephant
/
RSS Feed
What does sizing mean? In a classical project, we take a reductionist approach. We break the work down and assume we can accurately estimate the time a task will take in working hours. We then judge how many hours a team member has available in a week. And this tells us how long it will take to complete each task. In a complex Agile environment this approach is not realistic.
This podcast is AI-generated based on material from the “Agile Plays” website and book.
Transcript
Alright. Strap in everyone because we are diving deep deep into the world of agile estimation. It's a topic that a lot of folks find, well, tricky. You know? How do you estimate work when everything's always changing around you?
Sounds impossible. Right? Right. But you're in the right place. Whether you're, getting ready for that next sprint planning meeting or just, you know, insanely curious about how teams actually get things done in this agile universe.
We've got a ton of insights from experts, people who have actually been in the trenches, and we're gonna pull out the really useful bits and give you something you can actually use. So It's fascinating really because agile estimation, really turns our traditional ideas about project planning upside down. I mean, we're used to thinking about, you know, fixed deadlines, detailed gant charts, the whole 9 yards, but agile kinda throws all that out the window. It really does. I mean, it's like comparing building the Sydney Opera House to, like, navigating through a jungle that's constantly changing around you.
Uh-huh. One is all about precision and, you know, being able to predict everything, and the other is about being flexible, being able to adapt. Exactly. In agile development, we assume continuous development, which means the work is always evolving. So how do we estimate effort when the target's always moving?
Right. That's where the magic of relative estimation comes in. Okay. Relative estimation. I like the sound of that, but it sounds a little abstract.
It's more intuitive than you might think, actually. Instead of trying to, like, predict the exact number of hours a task will take, we try to understand the relative size and complexity of tasks compared to each other. Think about it like sizing up mountains. You know? A seasoned hiker can look at a bunch of different peaks and tell you which one's gonna take the most effort to climb, even without knowing the exact elevation or distance.
So it's about getting a feel for the level of effort involved, not necessarily about, like you said, nailing down that exact time, which actually sounds kinda like something we do naturally anyway. It is. We make relative estimations all the time in our daily lives. You know, when you're planning a road trip, you don't calculate the exact number of minutes each leg is going to take, but you have a sense of which legs are gonna be longer or shorter. Or even when you're cooking, you know, chopping veggies is gonna be quicker than roasting a chicken even without looking at a recipe.
Yeah. That's true. Okay. I'm starting to see how this applies to Agile. But how do you actually take that intuitive sense of effort and turn it into a more structured process for estimating work?
That's where story points come in. Story points are a unitless measure of relative size and complexity. So instead of saying, this task will take 8 hours, you might assign it 2 story points Indicating that it's relatively small and straightforward, a more complex task might be 8 story points, showing it requires significantly more effort or has more unknowns, or maybe even involves higher risk. Got it. So story points help the team speak a common language when it comes to sizing up work.
But here's where I get a little tripped up. If story points don't equal time, how do you plan your sprints and make sure you're not biting off more than you can chew? That is the $1,000,000 question. It's really, really crucial to understand that story points are not a direct translation to ours. A team's velocity, which is the number of story points they typically complete in a sprint, helps them understand their capacity.
But it's not, like, a perfect science. Teams need to constantly adapt and adjust their estimations based on what they learn as they go. So this is where it gets really interesting, and I know this is something that a lot of our listeners struggle with. You have a backlog with a mix of small very well defined tasks at the top and then these big hairy uncertain items further down the list. How do you even begin to estimate those larger ambiguous items?
It feels like comparing apples to, well, giant mysterious blobs. It's a very common problem. It's like trying to estimate the weight of an elephant by looking at a photograph. The key is to break those big items down into smaller, more manageable pieces. Remember that mountain range analogy?
You don't climb the entire mountain range at once. You break it down into individual peaks, and you tackle them 1 by 1. Right. Break it down. Size up the smaller pieces using story points, and then you can get a better sense of the overall effort required.
Exactly. And as you work on those smaller pieces, you gain more information, and you can actually refine your estimates for the larger item. Okay. So relative estimation, story points, breaking things down, it's all starting to click. But what happens when you have multiple teams, each with their own way of assigning story points?
I mean, that just seems like a recipe for chaos. You're absolutely right. That's one of the biggest challenges with story points. If different teams use different scoring systems, it becomes nearly impossible to compare their velocity or combine their efforts. It's like trying to build a house when every contractor is using a different measuring system.
Yeah. It can definitely lead to a lot of confusion and frustration. Imagine you're trying to plan a joint project, and one team's estimating in terms of, like, small, medium, large, while another's using a Fibonacci sequence, it just doesn't work. No. It doesn't.
So how do you bridge that gap? How do you get everybody speaking the same estimation language? There are a few strategies. One common approach is to have, like, regular calibration sessions where people from different teams get together and they talk about their understanding of story point sizing. They might even, you know, work through some sample tasks together and agree on, like, a baseline for how many story points each task should be worth.
So it's like creating a shared dictionary of story points. But even then, it seems like there's still room for interpretation. Right? What if one team tends to be more optimistic in their estimations while another is more cautious? Yeah.
That's true. That's where techniques like planning poker can be really helpful. Planning poker is a fun, interactive way to get the whole team involved in estimation, and it helps surface those different perspectives. Planning poker. I've heard that term before, but I'm not really sure how it works.
It's pretty simple, actually. Each team member has a deck of cards with different story point values on them. A task is presented, and everyone privately chooses a card that represents their estimate for that task. Then everyone reveals their cards at the same time. Uh-huh.
So it prevents those situations where one person's estimate kinda influences the whole team. What happens when there's a big discrepancy in the cards? That's where the real magic happens. The team discusses their reasoning, they can different perspectives, and they try to reach a consensus on the relative size of the task. It's not about, you know, arguing for your individual estimate.
It's about understanding why other people might see it differently. And coming to that shared understanding So it's a collaborative process that forces you to think critically and challenge assumptions. Exactly. And through that discussion, you often uncover hidden complexities or dependencies, things that might have been missed if you were just assigning story points on your own. It's like those optical illusions where you see one thing and then someone points out another perspective, and all of a sudden you see the whole picture totally differently.
Exactly. Planning poker can help teams see those different perspectives, and it helps them come up with a more accurate and realistic estimate. Okay. We've talked a lot about the mechanics of estimation, but let's kinda zoom out for a minute and talk about the bigger picture. You know, teams and organizational structure.
I was reading one of the sources and something really struck me. It said that the traditional term reports to can actually reinforce a hierarchical mindset, and that can be really detrimental in an agile environment. Such a really interesting point. That language of reporting to can create bottlenecks, and it can really stifle innovation. In agile, we want to empower teams to be self managing.
We want them to be able to make decisions quickly. That makes sense. But if everyone's calling their own shots, how do you maintain alignment? How do you make sure everyone's working toward the same goals? That's where the concept of management as a service comes in.
Instead of managers acting as the sole decision makers, they shift into a role of supporting and enabling teams. So it's less about commanding control and more about guidance and support. Exactly. Managers become facilitators. They provide the resources, the context, and the support that teams need to be successful.
They help remove roadblocks, they clarify priorities, and they foster a culture of collaboration and continuous improvement. And it all ties back to that idea of those small self managing teams we were talking about earlier. Right? No. Like Amazon's famous 2 pizza team rule.
Absolutely. The idea is that teams should be small enough that they could be fed by 2 pizzas. Smaller teams tend to be more agile, more communicative, and just more productive in general. They can make decisions quickly and adapt to change more effectively. So it's not just about saving money on pizza, although I'm sure that's a nice perk.
It's about creating an environment where teams can really thrive and work efficiently. Exactly. Large teams often get bogged down in communication overhead and decision paralysis. Keeping teams small and focused helps to minimize those issues. Okay.
So we have these small empowered teams. They're humming along, tackling those backlog items using their shared estimation language. But how do we know they're actually working on the right things? How do we make sure their efforts are aligned with the bigger picture, the overall business goals? That's where the concept of value streams comes in.
A value stream is the path an idea takes, you know, from that initial spark all the way to delivering value to the customer. It encompasses all the steps and activities involved from ideation and development to testing, deployment, and delivery. So it's like a map that traces the journey of an idea from, like, conception to impact. Exactly. And by understanding value streams, teams can see how their work fits into the bigger picture, and they can make sure they're focused on delivering real value to the customer.
But mapping out those value streams can feel really overwhelming, especially in a large organization. Where do you even begin? It starts with identifying the key stakeholders involved in the process, from product owners and developers to testers, marketers, and even customer support. Then you need to understand the flow of work, you know, pinpointing all the steps involved in bringing an idea to life. So you're basically creating a visual representation of the entire process from start to finish.
That's right. It's like drawing a map of the journey. An idea takes from a glimmer in someone's eye to a product or feature that delights a customer. And once you have that map, what do you do with it? Then you can start to identify bottlenecks or inefficiencies in the process.
Are there any handoffs that are causing delays? Are there any unnecessary steps that are adding complexity without adding value? It's like finding those traffic jams on your road trip and figuring out how to reroute around them. Exactly. And by streamlining those value streams, you can accelerate delivery, reduce waste, and ultimately create a more responsive and customer centric organization.
Okay. So we've got our teams humming along. We're mapping our value streams. But how do we actually measure success in this agile world? Lines of code, number of features shipped.
What are the right metrics to track? That's a crucial question and one that often trips up organizations. There's a real danger in choosing metrics that don't actually reflect meaningful progress or outcomes. I've seen that happen firsthand. I remember working with a company that was obsessed with hitting deadlines, but they ended up shipping buggy software that no one actually wanted.
That's why we need to focus on what I call robust KPIs, key performance indicators. A robust KPI is tightly linked to positive business outcomes. It's easy to measure a and d, easy to communicate so everyone understands what it means and why it matters. So it's not just about tracking vanity metrics that look good on paper, but don't actually tell you if you're succeeding. Precisely.
It's about choosing metrics that genuinely reflect the value you're delivering to customers and the health of your development process. So what are some examples of robust KPIs for agile teams? There are many, but I'll highlight 3 key areas to focus on, flow, quality, and value. Okay. Let's break those down.
Flow, we've talked about that. It's about ensuring that work is moving smoothly through the system without bottlenecks or delays. Right. And you can measure flow using metrics like cycle time, which is the time it takes for a task to move from to do to done, or lead time, which is the time from a customer request to delivery. So shorter cycle times and lead times generally indicate a healthier flow.
Exactly. Then there's quality. Are we delivering software that meets our standards and delights our customers? Metrics like defect rates and customer satisfaction scores can provide insights into the quality of our output. And finally, value.
Are we building the right things? Are we solving real customer problems and achieving our business goals? Right. And to measure value, you might look at things like customer engagement, revenue growth, or even the impact of new features on key business metrics. That's sort of about having a balanced view of success, taking into account not just speed and output, but also quality and impact.
Precisely. And by tracking these robust KPIs, you can get a much clearer picture of how your agile teams are performing and where you can improve. Wow. We've covered a lot of ground today, from the basics of relative estimation to the nuances of value streams and robust KPIs. It's like we've assembled a toolkit for navigating the complexities of agile estimation.
And what's key is that these concepts and techniques can be applied in a variety of contexts, not just software development. You're right. Whether you're planning a marketing campaign, designing a new product, or even organizing a community event, the principles of agile estimation can help you embrace change, make better decisions, and deliver value more effectively. So as we wrap up this deep dive, I wanna leave our listeners with a final thought provoking question. Think about the work you do every day.
What are those mountains you need to size up? Those value streams you need to map and those robust KPIs you need to track. Take these insights and start experimenting. Happy estimating.
Leave a Reply