Capabilities /

Software Self Defense 101: Improving Your Technical Estimates

By Josh Collins | February 11, 2016

photo credit J.King, ModernAnalyst.Com
photo credit J.King, ModernAnalyst.Com

Estimates are a necessary evil in every development organization. You have to size work in order to plan projects, but ever-changing scope and priorities will throw off even your best estimates. Nothing is worse than telling your client that what was estimated to take Y weeks will now take Y++ weeks and what would cost $X may now cost $X++. Not only are you behind in your timeline, you’ve also potentially compromised your client’s level of trust in you. Fortunately, these situations can be minimized and even avoided with some additional due diligence. Below are three guidelines toward feeling more secure in your estimates and your ability to defend them down the road.

1. Discover
Take the time to understand the scope, the problems you’re trying to solve, and the goals your stakeholders are looking to achieve. Ask questions that help you understand why your stakeholders are asking for the things they are. What sounds minor at first may have unforeseen tentacles — a simple request for a user interface change may predicate changes to a data model or a new backend web service. Take a little extra time now to avoid a lot of extra time later.

2. Get Real.
How often does your team get eight fully productive hours a day? That is, without meetings, or being slowed by a dependency, or being pulled away by the fire drill du jour? Estimate raw scope in terms of hours, but when you lay it on to the overall timeline, be sure to account for these real world demands. Set your team and your self up for success by being realistic.

planthework 2
photo credit Geek-and-Poke.Com

3. Assume Away.
As you walk through requirements and scope, break it down into as many granular line items as possible. For each line item, sketch out high level assumptions such as components needed or impacted. For example, a requirement may ask for two new fields to be added to a screen. This equates to changes to the UI but may also require additions to a database, adjustments to a backend service code, some minor business logic, and some tweaks to a report. Communicate these assumptions with your stakeholder, and if possible, have him or her validate them. Size the work based on these assumptions. Then document them in a level of detail such that you can explain the estimates weeks or months down the road. This will also help in managing scope later on in the project lifecycle. The bottom line is, it is much easier to explain a change in effort or duration, or navigate an unexpected issue when you can point to previously agreed upon assumptions.

A little extra time for research, a bit more respect for reality, and a lot more documentation can make a world of difference in your ability to plan and deliver at the standards, both of which your team is capable and of which your client deserves.


An Intro to RADD

At Janeiro Digital, our ultimate goal is to help businesses better achieve their goals so they can in turn better…

Read more

How To Win As You Build Your IoT Process

Whether you’re in the midst of your IoT journey or just figuring out how to begin, you must be able…

Read more

New Year, New You: A Guided Meditation on UX Optimization

A great user experience is the product of skillfully balancing the utility of intuitive user interactions with a polished interface.…

Read more
// // //