Collaborative Software Development Estimates
Software development estimates are often a major point of contention and misunderstanding. These problems are almost always rooted in participants having different language, expectations, and assumptions about the process. How many times have you seen something like the following?
Stakeholder: “When will that feature be done?”
Developer: “What do you mean? I finished that code last week.”
Stakeholder: “Uhhh… Nobody told me. Thanks! I’ll let our client know it’s ready.”
Developer: “Oh, well it’s not deployed yet so you’ll need to wait until that happens before you tell them they can use it”.
Stakeholder: “…”
There are multiple communication problems evident in this example, capped by the fact that neither party has the same idea of what it means for a feature to be “done”. It’s not that either party has the wrong definition, they just haven’t communicated well enough to understand each other.
Most high-functioning relationships between people collaborating around software estimates have some common elements of understanding. If we were to codify these elements, it might look something like the following, presented as an actual (tongue-in-cheek) agreement.
Mutual agreement between Developer and Stakeholder
We the undersigned represent stakeholders who need software developed, and developers that will build the software. For various reasons we need to collaboratively estimate how long this will take. To make sure both of us are happy with the estimate and ensure that expectations are met, we outline below our mutual responsibilities to each other and to the process.
Developer expectations of the Stakeholder
- The software you (the stakeholder) are expecting me to build has been fully described to me to the best of your ability, and I have had sufficient time to fully understand it.
- Giving highly accurate estimates requires significant time and effort, time that could be spent writing code instead. You (the stakeholder) will let me know how accurate the estimate needs to be: is this a significant contractual deadline that we need to commit to, or is it a low-priority feature where nobody will notice if it takes a bit longer than we thought?
- Sometimes there are too many unknowns and it’s just not possible to give an estimate with confidence. When I don’t feel able to give a good estimate, you (the stakeholder) will respect that I am giving you the best information I have. A bad estimate is usually worse than no estimate.
- Things change, and what we are building may need to be adapted or maybe even put on hold entirely for something else more urgent. I trust that you (the stakeholder) will do your very best to prevent these kinds of major shifts from happening, and when it does happen you recognize that any timeframes will need to be adjusted.
- I trust that you (the stakeholder) are asking for an estimate in good faith, and that you will present the information I give you accurately and fairly. I’m here to build software, and I view politics and posturing as a waste of time. If any of that happens and it leads to problems for me or my team, all trust will be gone.
- You (the stakeholder) won’t commit me to deadlines that we haven’t talked about, or promise anybody that we will complete any work that hasn’t been talked about. We will work together to understand anything that needs to be developed, including timeline and priority, before communicating about these features to others.
- You (the stakeholder) recognize that a timeline implies being able to be dedicated to that project, or that there is an expected number of interruptions and distractions that was built in to the estimate. If production unexpectedly goes down 6 times while I am building something and I get pulled into that each time for several hours, my estimate won’t still hold.
Stakeholder expectations of the Developer
- If I missed something when describing what I need built, you (the developer) will be understanding of the fact that I don’t know enough about software development to perfectly represent the needs to you. You will ask clarifying questions and take the initiative to understand what is being built, making a genuine effort to understand it rather than using the exercise to treat me as less intelligent than you.
- You (the developer) will provide a reasonably accurate deadline without a large amount of padding built into it. Since work expands to fill the time available, the timeline should be as realistic as possible based on the information we have so that we don’t encourage projects to take longer than needed.
- When you (the developer) estimate a timeframe for when software will be “done”, this will include all steps of the process including QA, deployment, etc. until the software is actually in the hands of our users. We will make sure we have a common understanding of what it means to have a feature “done”, and any estimates will consider that understanding.
- You (the developer) recognize that I will be using this estimate to make commitments to clients or other stakeholders. These commitments might not always have a date associated, but even speaking in generalities about when something might be done or what relative priorities different projects have can imply timelines.
- When you (the developer) give a timeline, it won’t be an idealized version of how much time it should take in a perfect world. If only half of your time will be spent on what you are estimating for example, the timeline will represent that. Saying something will take 40 hours can imply very different timelines depending on wether somebody can be completely dedicated to the project or wether they can only carve out 20% of their time for it.
- When a timeline is agreed to, you (the developer) will do everything you reasonably can to achieve it. Plans will start to be built around that date, and while I understand the need to be flexible we still need to make sure that we are doing everything we can to achieve those dates.
- If a timeline slips, you (the developer) will let me know. Just as I ask for you to be flexible in dealing with new information that affects a project, I will be flexible when adjustments need to be made. I ask that you inform me as soon as possible though, so that I can start adapting early in the process.
If organizations building software have a superpower, it’s the ability to work together well enough that software estimates can be used to effectively guide the whole business. The superpower isn’t that this kind of effective communication is a multiplier per se, it’s the fact that NOT getting it right can be a huge drag on the organization – and most organizations don’t get it right.
If you want to exercise this superpower at your company, build trust together. Trust has a foundation of strong communication, and this “agreement” can help foster the right kinds of communication to help give and receive accurate estimates, and more importantly to build trust around the process and its results.
