Software Estimation – Trading Perceived Effort For Outcomes
Experienced technologists know the variables in software development are nuts, and estimating to account for all possible outcomes doesn't work.
Watch or listen to this episode
YOUTUBE
SPOTIFY
APPLE
It’s human nature that businesses have a desire for software estimation.
For projects with a fixed scope, typical estimating methods can be off by as much as 70%. And that’s a product that doesn’t adapt to user needs.
If you desire the economic growth that comes from building winning products for customers, the numbers will be even worse.
The short of it? Don’t bother! Pick a budget for what you can afford each month, and let a qualified development team or consultancy tell you if they can build a minimum viable product (MVP) in 1/6th to 1/12th of that budget.
This will produce your core theory of value and two delighting features early, with monthly budget left over to adapt to changes.
If you find that the product needs to change spend some budget on those changes.
If you find that the product needs to improve in quality, spend some budget on beefing up testing.
Software projects don’t fail because the product couldn’t get built in time – they fail because they DON’T DELIVER VALUE high enough to justify the investment.
To reach this high level of value means spending less time envisioning, and more time ADAPTING.
The only way to do this is with a laser focus on the core theory of value, and a budget that will last through several feedback cycles.
Any time a product owner/manager or non-technical person of any sort asks for an estimate, they create anxiety in those doing the work.
Experienced technologists know the number of variables in software development is ridiculous, and systems that have been created so far to account for all possible outcomes fall far short of being helpful.
Though we may need to estimate whether we can deliver the core theory of value within a time frame short enough to get feedback, ongoing estimation should be unnecessary if budgeting of software is done on a subscription-based, value-focused basis.
Software businesses must ensure that insights about how the product is being used are recorded with every release of the product.
Minimal change must be introduced each release, to allow for A/B testing to determine whether a change had the desired impact on business outcomes.
How business outcomes are measured is specific to each business, but these must be determined and agreed upon BEFORE development of any feature that will impact them starts.
The effort of a successful software project focuses on measuring whether each release is getting the business CLOSER TO AN OUTCOME, not closer to completing a FIXED SCOPE OF WORK!
This paradox can be hard to wrap your head around, but it must be fully appreciated to operate in a truly lean fashion.
Determine what you can spend per month, get started, and adapt…
TRUST THE MARKET, not your ego!
Resources
- Minimum Viable Product – Letting Software Companies Help You Profit
- Agile Project Management – Is It Stopping You From Being Agile?
- Lean Software Development – It’s About Uncertainty!
- “Principles of Product Development Flow” on Amazon
About the THRIVING TECHNOLOGIST show
On YouTube and all major podcast networks, Jayme shares teamwork and leadership strategies, guidelines for healthy company culture, and stories about real projects so you can have a sustainable career in the software industry.
Jayme Edwards
A family man and veteran of nearly 40 software projects, Jayme experienced many wins and losses over his career as an architect and consultant.
Now he's coaching software developers, managers, and business owners to overcome challenges in the IT industry - so they keep growing.