This episode is part of a wider mini-series looking at Estimation in Software Development. In last week's episode, I asked you to think about what the term "estimate" means to you, your team and your organisation. In the episode I talked about different definitions that could easily be conflated - the amount of effort, a target, and a commitment. In this week's episode I want to continue the discussion by looking at estimates "proxies" - what they are, why they can be useful and how to avoid the trap of confusing them for scheduling.
Or listen at:
Published: Wed, 11 Dec 2024 01:00:00 GMT
Links
- #189: Estimation - a review
- #194: Estimation - What are you actually asking for?
- Software Estimation: Demystifying the Black Art by Steve McConnell
Transcript
Hello and welcome back to the Better ROI from Software Development podcast.
This episode is part of a wider mini-series looking at estimation in software development.
I started the mini-series in episode 189 by providing the following guidelines. 1. Don't invest in estimates unless there are clear demonstrable value in having them. 2. Agree what a valuable estimate looks like. This will likely be a desirable level of accuracy and precision for an estimate. 3. Provide the team with training and time to develop their estimation skills. 4. Collect data on points one to three and regularly review if you have the correct balance.
Subsequent episodes take a deeper dive into specific aspects for estimation in software development. And while long-term listeners may find an amount of repetition across the series, I wanted each episode to be understandable in its own right, as much as practical, to be self-contained advice.
In this episode I want to discuss estimate proxies, what they are, why they can be useful and how to avoid the trap of confusing them for scheduling.
In last week's episode, I asked you to think about what the term estimate means for you, your team and your organisation. In the episode, I talked about different definitions that can be easily conflated. The amount of effort, a target, a commitment.
In the episode, as I have done many times in the series on estimation, I reference back to Steve McConnell's book, Software Estimation - Demystifying the Black Art, and reference his first tip:
"Distinguish between estimates, targets and commitments."
Alongside estimates, targets and commitments, I also see proxy metrics adding to this conflation and ensuring confusion and dysfunction. Thus, in this episode, I want to look at proxy metrics.
So, what is a proxy metric?
You will likely be aware of them as either t-shirt sizing or story points. They are generally a way of talking about the size of a piece of work in an abstract manner.
So for example, if discussing three separate pieces of work, if I told you one was a small, one was a medium, and one was an extra large, you already have an idea of the comparative size of the pieces of work, without even having to discuss the pieces of work in question.
And this is their key benefit, an easy, light way of sizing a piece of work in comparison to another.
This technique is commonly used by development teams to create an understanding of the relative size of a series of pieces of work.
And the factors used to arrive at that size could be anything that the team feel appropriate. Anything from the amount of code or changes expected, to the complexity to test and deploy, to the risk of security vulnerabilities.
Whatever the team find useful for comparison purposes is on the table.
However, for the rest of this episode, I will use size as a shorthand. But please keep in the back of your mind that it will be team dependent on what that actually means.
So, I've mentioned t-shirt sizing and story points. Let me expand on those a bit.
T-shirt sizing is a nice easy metric to understand. We all understand that t-shirts come in different sizes. So trying to convey that there is a difference in size between two pieces of work by describing one as a small and one as a large helps us to articulate that there is a reasonable difference between the two pieces.
The problem is that the reasonable difference can be open to interpretation and can be a source of misunderstanding.
Even in a single store, seemingly identical t-shirts can differ in size, even though they're all medium, but it's the individual manufacturer's idea of medium.
And this leads us to have a different feel for just how much of a difference there really is between two or more adjacent sizes. I know that I'm not going to fit a small t-shirt, but my wardrobe contains a selection of medium, large, and even the odd extra-large, dependent on the manufacturer's generosity.
So t-shirt sizing is easy for communication, but maybe not so good for precision.
Story points go a little way to address that.
Story points are a number vaguely based upon the Fibonacci sequence. For example, 1, 2, 3, 5, 8, 13. The Fibonacci sequence is used to force differentiation between pieces of work by adding the two most recent numbers to get the next one. So our next number in the sequence will be 21, the sum of 8 and 13.
This helps to provide a differentiator as a number gets larger, which helps to highlight the wider levels of uncertainty the larger a piece of work gets. So while the gap at the start of the sequence is relatively small, it can quickly grow to being a difference of tens and then hundreds of story points. This differentiator gets us some way to help to indicate the size difference better than t-shirt sizing.
To help us understand the use of proxies better, let's discuss how a team would use them in their delivery process.
A new team has been stood up with a series of 10 pieces of work to do.
To get a comparative size of each piece of work, the team choose to discuss each and assign a number of story points to each of them. They start by taking the seemingly simplest of the tasks. If they are not comparing to anything else, they may choose to assign this one story point.
Then they take the next piece of work and discuss comparatively to the first. They may feel it's the same size, thus can be assigned one story point as well. Or they may feel that on discussion it's actually smaller, in which case they may recalibrate the previous story to something higher. Or they may feel it's larger and pick an appropriate number in the sequence.
During this exercise, they might find they don't actually have enough information to assess a given work package. Or find a work package that's so large, it's an obvious outlier. Maybe a candidate for something that needs to be broken down into smaller work packages.
They will continue to work through the 10 pieces of work, discussing them and agreeing on a comparative size.
Knowing that size can then assist the team in ordering and planning.
Compare this to when you think about your daily schedule. You're probably doing much the same thing subconsciously. You're mentally reviewing the tasks you need to accomplish throughout the day. You're unlikely to know the precise time each will take, but you'll have a fair idea how they compare to each other. And this comparative ordering helps you to plan your day. At this point, you may be forgiven for thinking, the team have sized the work with either story points or t-shirt sizes, I must be able to turn that into effort, and from that, a schedule.
And unfortunately this is a mistake that many others have made before you.
Just as with your daily tasks, it's comparative, not absolute, thus generates more questions than it does answers. Neither a t-shirt size of medium or five story points is expected to relate to a specific level of effort or elapsed time. But the mistake is often made that if we just assign a period of time to the proxy, we can use that for estimates.
Take, for example, our medium t-shirt size. I've seen it commonly equated to a range of time, something like greater than one week, less than a month, which is too broad to be useful for planning.
For example, if those 10 pieces of work that we talked about earlier had all been estimated at medium t-shirt size, how long does it take us to do all the work? Well the shortest is 10 weeks, the longest is 10 months, so our average is probably somewhere in the middle.
And while story points can seem more granular and provide a better transition to effort or schedule, the problem still exists.
Even if we put aside the practicalities of mapping proxy metrics to some form of estimate, we are repeating the same mistake we tried to solve in the last episode, having a mismatch of language and interpretation. We have a team using story points or t-shirt sizing for one thing, then we have a project manager trying to interpret that for a different use. Yes, they may seem very similar, but then again so do an estimate, a target and a commitment, and we discussed in last week's episode how that can lead to dysfunction and a breakdown of trust.
Better yet, if you want an estimate, or even better a proposed schedule date, then be explicit.
While I don't doubt that a team will use any proxy as a starting point for any conversation on schedule day, there is certainly not going to be a linear correlation between proxy value and schedule date, and neither should there be. There are entirely different things serving entirely different purposes.
Don't try to divine meaning where there isn't any.
In this episode, I wanted to discuss estimate proxies, what they are, why they can be useful, and how to avoid the trap of confusing them for scheduling.
Proxy metrics like story points and t-shirt sizes have gained popularity in Agile software, as they provide a simple shorthand for teams to talk about size, scale, and even complexity of a given piece of work. In many cases, these metrics are more than enough to replace the need for detailed estimation techniques.
However, they can easily be conflated with effort and the schedule date by well-meaning leaders with a traditional project management background. They are not the same thing, no matter how similar they seem to be.
Again, we must remember that software development is a team sport. It's about the people. Thus, we should always be open and honest in our dealings. Otherwise, trust breaks down and the team ceases to function. Thus, if you want a schedule date, please be explicit in asking for it.
In next week's episode, I want to encourage you to mentally separate estimation and planning. They are often conflated, which leads to confusion, distrust and dysfunctional behaviour. An estimate is generally part of a plan, and that plan can be the outcome of the act of planning.
Software development can't be delivered without planning, even if it's the most cursory of activities.
Software development can be delivered without an estimate.
Yet, I often find more weight given to the estimate, rather than the planning.
Thank you for taking your time to listen to this episode, and I look forward to speaking to you again next week.