Navigating the Uncertainties of Sprint Estimations in Scrum Teams
Today, let’s delve deep into a fascinating question which is, “How does a scrum team estimate what can be delivered in a single Sprint?”
It’s a great question, and I must admit, the ultimate answer might surprise many - maybe they don’t!
Grab a seat as we unravel the intricacies of Sprint estimations! 🚀
The Great Dilemma - Estimations or Size?
As per the scrum guide, surprisingly, the terms ’estimate’ or ’estimation’ are nowhere to be found on its pages.
Instead, it emphasises understanding the ‘size’ of things on their product backlog, diverging from the common notion of estimation. 💡
While estimation tools and techniques stand as excellent resources, their prime utility, as I see it, is to foster a profound understanding among developers, the product owner, and stakeholders about the elements in the product backlog.
In my experience, this comprehension tends to be far more valuable than pinpointing a specific timeframe, which can often be misleading.
Yet, I often lean on these tools to bolster teams’ understanding of the items on the product backlog rather than pinpointing a fixed time frame.
The Creative Process: Unpredictable & Uncharted
Consider this scenario, which may sound outlandish, but think about it. What if someone asked you to write a book on political leadership in the UK?
Could you instantly decipher how long it would take? ✍️
Honestly, you don’t know; you can’t answer that question.
It’s virtually impossible to predict the timeframe for such a creative endeavour, as it’s laden with unforeseeable obstacles and surprises that bring in a high level of variance.
Just as with crafting a product that doesn’t exist yet, predicting a precise timeframe for a book is fraught with uncertainty due to unforeseeable challenges and surprises that might occur along the way.
Embracing Uncertainties in Agile Strategies
Building a product is akin to venturing into unknown territory. Your approach, tools, ideas, and even architectural choices are yet to be formulated.
This unknown facet leads to the inevitable element of surprise, making precise estimation a bit far-fetched. 🔍
So, when it comes down to what can be delivered in a Sprint, the truth is we take educated guesses akin to many others.
Remember, your Sprint goal should encompass only a portion of the Sprint, allowing room for adjustments and realignments as you might often realise that tasks could take more time than anticipated.
Embark on Your Agile Journey
I invite you to join my Agile and Scrum courses to delve even deeper into these nuances and cultivate a robust understanding. 🎓
We will navigate the unpredictable yet exhilarating journey of Agile project management. Let’s learn, adapt, and grow together!
That’s a great question. So the question is how does a Scrum team estimate what can be delivered in a single Sprint? And the ultimate answer is maybe they don’t. The Scrum Guide does not have the word estimate or estimation appear anywhere within its contents. It uses the word size. The team should be able to understand the size of things on their product backlog, which is not quite the same as estimate.
Estimation is a great tool. There are various estimation tools and techniques that teams can use. I generally use those tools and techniques to help teams understand the things on the product backlog better because I find it’s much more valuable, much more important to have the developers and the product owner and the stakeholders understand things than it does to say it’s going to take this amount of time. Right? Because ultimately, if we say it’s going to take this amount of time, we’re talking out of our butt. There’s no way for us to know how long a creative piece of work is going to take. It’s just not possible.
Think to yourself, I’d like you to write a book on the topic of leadership in the United Kingdom, political leadership in the United Kingdom. Then how long would it take you to write that? I want you to tell me off the top of your head how long will it take you to write that? You don’t know. You can’t answer that question. You could probably take a rough guess, but you might be orders of magnitude under or orders of magnitude over because you don’t know whether you’re going to get writer’s block. You don’t know whether you’re going to not be able to find a critical piece of information that your brain thinks you need. You don’t know any of those things. You can’t predict those things.
So the surprises that happen when you’re building products, things you don’t know, give you a very high level of variance. So the idea that you can estimate things you don’t know how to do yet is just ridiculous. It’s very different from the story of if I asked an electrician to estimate how much it will cost to rewire my house. That’s something that they probably can estimate because they’ve done houses like mine before. Right? My house is not that much different from anybody else’s house. The way you wire is not different from anybody else’s house.
When you’re building a product that doesn’t exist yet, the tools and techniques and practices and ideas and architectures and ways of doing things don’t exist yet. You have to come up with those, and that’s where those surprises come in.
So how can a team estimate what can be delivered in a Sprint? I think they take a guess like everybody else does. That’s why your Sprint goal should never be the whole Sprint. It should only be part of the Sprint because you might be wrong. You might think this will take two of the 10 days that you have in your two-week Sprint, and actually, it takes five. Okay, well, we’ve built that in by having a Sprint goal that’s much more targeted, and we are going to drop some of the other stuff that we brought into the Sprint that we thought we would be able to do, but maybe we can’t.
So the answer ultimately is you don’t. Thanks for watching the video. If you enjoyed it, please like, follow, and subscribe. I always reply to comments, and if you want to have a chat about this or anything else Agile, Scrum, or DevOps, then please book a coffee with me through Naked Agility.
