Using software estimations to account for scope discovery
This article brings together two of our favourite discussion points — software estimations and scope management.
The best way to illustrate the value of accounting for scope discovery is to tell you about my latest experience building Ikea furniture. I bought a new TV cabinet after what felt like hours walking in circles with the faint smell of meatballs tempting me. I got home and felt motivated to put this cabinet together immediately. Ever the optimist, I gave myself 90 minutes to put it together before I had to leave. Some readers might be thinking; that’s way too long to put together a cabinet (unfortunately the extent of my handy work skills isn’t the subject of this article).
Once I unpacked the items I realised that I didn’t account for something that would significantly impact my estimates. There was no consolidated set of instructions. Each part of the cabinet had its own set of instructions but there was nothing telling me how to bring each part together. Now, I wasn’t building anything more than I initially estimated for. There was no scope creep. I made a discovery early on that had an impact on my estimations.
Similarly, discoveries are made in software development that aren’t necessarily anyone’s fault. The product owner hasn’t allowed the scope to creep and the development company hasn’t failed to deliver the requirements. The bottom line is that it affects the delivery time, which impacts project costs and release times.
We’ll use historical data to determine what the average amount of discovery has been as well as how it can be addressed during the estimations stage.
How much discovery can you expect?
We ran the numbers on some previously projects to determine what the level of discovery we can expect is.
On average we have seen a 15% increase in tickets as a result of discovery.
The information used for this statistic looked at the number of tickets that were completed during the ﬁrst milestone of past projects. It was then contrasted with the number of tickets estimated, and the change requests were removed — giving us our percentage of discovery tickets.
On average we have seen a 15% increase in the number of tickets due to discovery. This doesn’t necessarily equate to a 15% increase in time. That is determined by the size of each of those tickets. What is certain is that discovery tickets will have an impact on the length of the project and it would be short sighted to simply dismiss them.
How can you handle discovery tickets using software estimates?
Step 1: Acknowledge
One of the worst mistakes you can make is assuming everything will go exactly as expected. Assuming that the exact backlog will be developed within the exact estimates is a naïve approach to take. It’s important to acknowledge that there will be a degree of variation and plan for it.
Step 2: Incorporate it into your estimates
Once it’s recognised, the next step is to plan appropriately for it. We do this through the estimations process. We’ve taken a scientiﬁc approach to software estimates you can learn about here. We apply a factor of 10% to estimates in order to account for discovery. As previously mentioned, the ticket growth of 15% doesn’t always correlate to an equivalent increase in time. We’ve found that the correlation between discovery tickets and time is somewhere between 0 and 1. You may ﬁnd that yours is higher or lower depending on your process.
Step 3: Reﬁne
Chances are you won’t guess right the ﬁrst time. The closer you track your discovery tickets, the more accurate you can be when you look at reﬁning that data. Our recommendation is to create a discovery issue type in the project management software you use. Be vigilant when monitoring and labelling issue types.
Give me the summary;
- It’s important to incorporate discovery in your estimations.
- Our analysis has found there is a 15% increase in tickets from discovery.
- Ticket increase doesn’t correlate exactly with time.
- We allow for a 10% discovery growth during the scientiﬁc estimations process.
- Measure and reﬁne your process to determine what that percentage allowance should be for you.