This episode is part of a wider mini-series looking at Estimation in Software Development. In this week's episode, I want to discuss what the term "estimate" may mean to you and the colleagues that you work with. The term 'estimate' is often used interchangeably to mean the effort required, the target completion date, or even a commitment to complete the work by a specific date. Often the meaning of an "estimate" changes between people within even a single team, let alone a organisations - thus it is often a cause of friction and dysfunction due to it being in "the eye of the beholder".
Or listen at:
Published: Wed, 04 Dec 2024 01:00:00 GMT
Links
- #189: Estimation - a review
- #191: Estimation - what is a valuable estimate
- #192: Estimation - Predictability vs Optimism
- Software Estimation: Demystifying the Black Art by Steve McConnell
Transcript
Hello and welcome back to the Better RIO from Software Development podcast.
This episode is part of a wider mini-series looking at estimation within software development.
I started the mini-series back 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 want each episode to be understandable in its own right, as much as practical, to be self-contained advice.
So in this week's episode, I want to discuss what the term "estimate" may mean to you and the colleagues that you work with.
The term estimate is often used interchangeably to mean the effort required, the target completion date, or even a commitment to complete the work by a specific date.
Often the meaning of an estimate changes between people, within even a single team, let alone an organisation. Thus it is often a cause of friction and dysfunction due to it being in the eye of the beholder.
It's incredibly common for it to mean different things to different people, and from this, friction and dysfunction can arise. Thus, I'd like to spend some time going through what those might be.
As I have done previously in this mini-series on estimation, I reference back to Steve McConnell's book, Software Estimation - Demystifying the Black Art. Within it, he provides a list of tips, and his number one tip is
"Begin quote, Distinguish between estimates, targets and commitments."
While a simple comment and maybe one easily overlooked, it is arguably one of the most important concepts to consider when talking about estimates.
Back in episode 191, I introduced the shorthand of "Valuable Estimate", an estimate that is desirable for the organisation asking for it. And for it to be valuable, it would likely need to have an acceptable level of accuracy and precision.
Accuracy of an estimate being how correct the estimate was to the actual value. Precision of an estimate being how close to the actual value we are attempting to be.
As a software developer versus a project manager versus a stakeholder, I may have a different understanding of not just the acceptable level of accuracy and precision, but also the scope of work being estimated.
I talked a lot in episode 191 about accuracy and precision, so let's explore the different understandings of the scope of work.
As a software developer, I may be estimating the effort involved to do the work.
As a project manager, I may be expecting a target date by which the work is done.
As a stakeholder, I may be expecting a commitment.
So, as a software developer, I could be giving a free month effort estimate.
As a project manager, I'm treating that 3 months from today as a target, without taking into account other work, holidays, sickness, and a myriad of other factors that influence scheduling.
And as a stakeholder, I'm taking it as a commitment to have it done by that date.
So, if we combine that with the differing view on acceptable levels of accuracy and precision, we could have the software developer with a low-accuracy three months and a stakeholder with a high-accuracy commitment date.
So the developer and the stakeholder may be talking about the same thing, but have entirely different expectations.
Language is nuanced and often overloaded by individuals' own biases and expectations. Thus, is there any surprise that confusion ensues?
So, how do we handle this?
We need to ensure clarity right through the communication chain. We need to be clear and precise in exactly what we are providing.
Which itself comes back to a common thread throughout the series - What question are you really trying to answer? What is the problem trying to be solved?
If we are trying to be clear and precise in exactly what we are providing, it helps to align that to the why we are being asked for the estimate in the first place.
It may be that the effort level is needed to produce costing, maybe even for the staffing of the work. If so, then that estimate as an amount of effort may be the best metric.
Or it may be there are linked business activities to the end result like a marketing campaign. Thus, a commitment date is needed.
Again, every circumstance is going to be different, and it comes back to the "why" question.
But, for the purposes of this conversation, let's say we were providing an estimate to stakeholders for an ongoing series of work.
My personal preference is rather than providing an estimate of efforts, it is to favour breaking the work down into value-delivering chunks and to draft a schedule of dates based on the iterative delivery of those chunks.
I find that schedule dates provide a better language when talking to those outside of the immediate delivery team. Talking to your average CEO about 3 months of development effort is less tangible than saying by the 1st of October.
Largely, the CEO doesn't care how the work breaks down. They want to understand when they can be receiving value from that work.
If you're having a new kitchen, you aren't interested in the effort to produce it in the factory. You want to know when you can invite your friends and family round to show it off.
It also encourages us to think about the piece of work as a team, rather than potentially as an individual. It encourages us to think about things that will need to happen to get that piece of work into production.
That 3 months of development effort may not have taken into account all the efforts to take code from the developer's machine to being fit for use. We may have forgotten to think about provisioning activities and costs. Where does the software run? How does a user access it? Validation checks such as security, load, quality assurance. Operational practices, how is it fixed at 3am on a Sunday morning? Indeed, is anyone meant to be monitoring it at 3 o'clock on Sunday morning? Any accreditation such as federal or industrial, etc, etc.
All of this falls into the scope of the work.
While practices like DevOps help us bring much of this thought process earlier into the development process, it still needs to be considered in addition to the act of writing code.
In an established environment, something as simple as a checklist could help us to avoid missing critical parts of the full software delivery lifecycle in your scheduling. As an aside, checklists are great to build up as part of improving predictability, as I talked about in episode 192. The schedule also helps involved parties to comment. For example, if our schedule date suggests that we are going to interrupt a target team during the busiest part of their year, it may suggest we need to push the schedule further out so that the team can accommodate it more comfortably.
Ultimately, talking in terms of a schedule helps us to align as a group.
You may be asking, assuming that we have a schedule date, should it become a commitment?
My default stance is no.
I've certainly heard project managers tell me "don't worry, you won't be held to it", when asking for a schedule. But experience and scar tissue tells me that more often than not, I will be held to it.
That experience and scar tissue tell me it's easy for something to become a commitment, and almost impossible to adjust that commitment later without negative ramifications for trust in the team, which is understandable if the word commitment is used.
While building a schedule with all the involved parties can certainly make any date more likely, partly because the amalgamation of thought and partly because of the consensus, there is still likely to be too much that is either a known unknown or an unknown unknown to turn it into a commitment.
For me, it is simply unlikely that the confidence will be high enough to permit that.
But is there a danger of the schedule being misinterpreted as a commitment?
Of course. We've already discussed how language is nuanced and often overloaded by individuals' own biases and expectations.
And the further removed the beholder is from our delivery team, the more likely that our schedule date is likely to be misinterpreted as a commitment.
So, how do we handle this?
There are a few things that can help, but ideally you should be working towards an organizational wide shared understanding of terms like "scheduled date". If your organization can gain a shared understanding of what a scheduled date does and doesn't represent, the easier those conversations can be.
This idea of organizational norms is going to sound fairly obvious to anyone who's been through a transformation process in the last 10 years. Most transformation processes will bring with them language and terms that need to be clearly defined for an organization to have clarity.
We can think of those norms as an organizational glossary, a definition of what the organization can expect any given term to represent.
In this case, we will want to consider what should or shouldn't be assumed by a schedule date. Again, these are things that will differ from organisation to organisation. But I think we should be considering things like: * Should the work be live by the schedule date? * Should we be expecting to receive any value from the work? My personal preference is yes. * Should we be expecting to hit the scheduled date every time? Again, my preference is no. Otherwise, we are turning them into commitments. Rather, we should be thinking them as an acceptable and practical level of predictability we can work with. Maybe eight out of 10 being a reasonable expectation. * Should others be using that date to initiate other activities, such as a marketing program? My preference is a cautious yes. If we aren't expecting to hit the scheduled date 100% of the time, then we need to operate with a level of caution when planning related activities. And the appropriate level of caution is obviously dependent on the activity. An in-house training program can exercise a lower level of caution than a multi-million pound marketing campaign.
Whatever that schedule date means to your organisation, it should be codified and communicated often. For smaller organisations with maybe a single development team, this should be relatively easy. With a large organisation with tens or even hundreds of development teams, this can become a programme-level activity in its own right.
But regardless of how it's communicated, it helps to include any relevant definitions, risks and assumptions explicitly any time the scheduled date is shared, be it in emails, presentations or reports.
Remember to use the adage, if you think you've said it enough, say it again.
If you've not come across the adage before, it emphasises the importance of repeating a message to ensure understanding and retention, especially in contexts like leadership, teaching or any situation where clear and effective communication is crucial. It reflects the understanding that people often need to hear information multiple times before it is fully absorbed and understood. This concept is widely recognised in fields related to communication, education and management.
This all might seem expensive and a lot of effort, but as I've said a number of times during this series, producing estimates cost. Producing valuable estimates cost a lot.
And I struggle to see how an estimate can be valuable if it's not clearly understood by all stakeholders.
In this episode, I wanted to ask you to consider what the term estimate means to you, your team and your wider organisation.
As Steve McConnell advises in his tip number 1 from Software Estimation - Demystifying the Black Art:
"Distinguish between estimates, targets and commitments".
We so often forget that software development and product delivery is a people-driven endeavour. We focus on the technologies or the process. We fail to consider the human side of it, the connections and the trust that we need as humans needed to work at our best, to be happy, to be content and to feel the psychological safety to bring our true self to our everyday activities.
And unfortunately, the dysfunctions that evolve within the same team as individual members conflate an estimate, a target and a commitment, soon erode any chance of psychological safety. Differences of understanding can quickly reduce trust both within the team and with the organisation's expectations of a team.
Thus, why in this episode, I have asked you to think about what that definition is for you, your team, and the wider organisation. And then to communicate that definition. If anything, over-communicate, codify it, carve it into stone tablets if it helps. But the clearer the definition, the more trust that can be built around it.
In next week's episode, I want to take a look at estimates by any other name. Proxies for an estimate. Proxies like t-shirt sizing or story points.
While these can be useful planning tools, they again can be conflated to an estimate. How often do we hear a description of a small as a "week's work", or having a conversion rate for story points?
This just adds to the confusion and dysfunction discussed in today's episode.
Thank you for taking the time to listen to this podcast. I look forward to speaking to you again next week.