I promised I’d post something on the curious case of agile and fixed bid projects. These two concepts don’t often find themselves sitting side by side, which is a bit of a curiosity to me.
As I wrote this post, it quickly became apparent that this wasn’t going to make it in one post. Technically, it would fit in a single post, but you’d lose the will to live before you finished, so you’ll find a part 1 and part 2 to this topic (this is part 1 if you’re not paying attention). This post will deal with the estimation factor, the next will deal with Fixed Bid projects.
Onward!
No matter where I’ve worked there’s always been someone holding the purse strings who wants to know:
When will it be done and how much will it cost?
Maybe I’m just unlucky.
The truth, whether we want to recognise it or not, is that there is an expectation that we can answer the cost and time question. We need to plan spending on hiring and resources and of course we need to plan our marketing spend. As engineers, we can choose to ignore all of this, but that is just a fast route to breaking your company.
It’s not just the big guys
Small, nimble – dare I say agile – companies tend to eschew bureaucracy preferring to believe that things like budgets and estimates only belong in large, lumbering organisations. We’re too quick, to smart, too agile to be bogged down by such arcane requirements.
Nonsense
To those of you in this mindset, I would challenge you to engage in a conversation with a venture capital firm. Present your world changing concept. When they ask (and they will ask) how much money is required to finish your product and when will you launch simply answer:
We’re agile, so we’ve prioritised the most important features first. We can launch at any time.
Fantastic they’ll say, we’ll invest, but launch immediately. It’s at this point that the conversation will start to get awkward as you try to explain that ‘we can launch any time’ actually means ‘not now’. You might go with a slightly more palatable version:
We’re lean and working towards a Minimum Viable Product – we call it MVP. We’ll launch when the MVP is ready.
Excellent, someone with a plan they’ll say, when will MVP be ready to ship, and could it be quicker if we invest more?
The bottom line is this, you need money to keep the dream alive, and the people holding that money want to know how much and for how long.
This is true for internal projects in large companies, bespoke solutions for external clients and product development projects of any size, even if it’s your own. You need to be able to produce an estimate, the quality of that estimate you need is determined by who’s holding the money.
Estimation
Estimation is one of the dark arts of the software world. I honestly believe that when we return to the age of burning witches and heretics we’ll be throwing the people that can smoothly plaster a wall and the people who can accurately estimate a software project onto the pyre with them.
There are numerous books out there that deal with the topic but two that I would recommend are Steve McConnell’s Software Estimation which is timeless and similarly Mike Cohn’s Agile Estimation book which offers a contemporary look at the subject.
Estimation Bluffers Guide
As is my wont, I offer my ‘bluffers guide’ to estimation:
Baseline assumptions
- Estimation is an iterative process
- You can’t just produce an estimate and leave it there
- Your assumptions will change over time, as will the circumstances, so too must your estimate
- Each cycle of the estimation should achieve the following
- Dissection of the information into increasingly granular pieces of functionality
- Increased accuracy on the predicted size of those pieces of functionality
- More granular time estimates for each of those pieces of functionality
- You can’t estimate what you don’t understand
- You’ll need to perform some analysis and at the very least come up with a considered approach to the project
- The nature of the estimate depends on the audience for that estimate
- Your customer, for example, may only be interested in man-hours, not t-shirt sizes
Simplified Process
- Study the requirements and break into large chunks
- Produce a low fidelity estimate based on the relative size of those chunks
- The relative size should be T-Shirt sizing or similar
- S, M, L, XL, XXL
- Anything larger than that, you need to break down some more
- The size should allow you to give a ‘finger in the air’ estimate with a margin for error of 50% – 60%
- Estimate in months or at best weeks
- The relative size should be T-Shirt sizing or similar
- Engage Business Analysts / Product Owners to elaborate on the requirements for the feature
- Based on priority, as features move closer to development
- Have an architect review the story, identify dependencies
- Have the team produce a medium fidelity estimate
- Use some of the agile tools such as planning poker
- Limit estimate to relative size using story points, which is more granular than T-Shirt sizing
- Using your teams’ velocity produce an estimate using those story points. Your margin for error should be 15% – 30%
- As a feature is entering a sprint
- Dissect the feature into granular tasks
- Tasks are estimated in hours
- Split each task into chunks of no more than 4-6 hours
Fundamental Requirements
Your estimation process will bubble out an estimate with a margin of error, but the accuracy of that estimate, or perhaps more importantly the ability of your organisation to deliver on that estimate is underpinned by a couple of very fundamental factors.
- Mature teamsThis is vital for Agile, but equally it’s critical for delivering on an estimate. If the team don’t know each other, don’t know the organisation, don’t know the problem domain, don’t know the technology stack or are just new and fresh out of college then they are not mature in this context. If you don’t have a mature team, you can’t trust the estimate.
- Mature SystemsYour systems include processes, the tools the team will use, the technical environment and the maturity of the organisation. Any or all of these factors can impact your teams’ ability to deliver.
- Mature CustomersThis factor is almost always overlooked. An immature customer may be breaking into a new market, or may be defining a new market, they may be in a period of change where the past rules no longer apply. Whether your customer is internal or external, their maturity level will impact the quality of information that they are providing. Low quality information will result in a low-quality estimate.
Accuracy
Even after you read the books, study function point estimation, story point estimation, planning poker and all the other techniques will you end up with a 100% accurate estimate?
No.
This is a guessing game; it’s not like estimating a building project or a civil engineering project. The elements of a software project that can be definitively measured are minimal. It’s not a question of how quickly code can be written, it’s a question of how quickly can you solve a problem that you haven’t solved before.
If you believe you have arrived at an estimate that is 100% accurate, by which I mean that you can guarantee hitting the date no matter what happens, then I would suggest that you have added so much padding and contingency that a blindfolded monkey could make the date. Simply put, you’re not trying hard enough
Force the rules
Estimation is where development organisations inevitably run afoul of the other areas of the business, particularly finance. It can be challenging to explain the difficulty in coming up with an estimate to those who haven’t experienced the processes of software development first hand.
The only approach that I have used that is in any way effective when dealing with this situation is:
- Publish your estimate early and highlight the margin for error
- Never negotiate this estimate. it makes the other side think this guess is subject to debate, which it can’t be, it’s a guess
- For every pressure for a lower number, offer a range that expands the upper number by the same factor as the lower number
- For example, you might say, our initial estimate indicates a duration of 100 to 150 elapsed days
- Under pressure, you expand the range from to 80 days for the lower bound, this is a 20% drop, so increase the upper bound by 20% resulting in a new range of 80 to 180 elapsed days
- Keep emphasising that it’s a guess, not a ‘take it to the bank’ number
- As the team progresses with their analysis, publish a revised estimate based on what you now know
- Don’t wait to be asked, publish the number as a matter of course
- The new estimate does not have to relate to the last numberThis is a huge challenge for people. It’s easy to massage an estimate to align it with the last estimate rather than admit that the first estimate was not accurate. Resist the temptation; it will only add to the pressure in the project as the estimated date looms large.
- When the feature enters the development cycle, where the code will actually be written, publish the final estimate based on the task breakdown
The bottom line is that different parts of the organisation view estimates through the lens of what they need to achieve. Financial people need to forecast spend and revenue; marketing people need to plan campaigns and so on. You need to be clear on what the estimate will do and how accurate it is. You can’t negotiate a guess, so don’t start.
Bows and Arrows 