In the past, I have made numerous incorrect estimations, often being overly optimistic about the implementation process. I would solely focus on the smooth and successful paths without considering potential obstacles. Additionally, I would sometimes hesitate to provide higher estimates or fail to ask enough questions to fully grasp the project's scope. While we now follow an agile working style with constant sprint planning, it remains crucial for someone starting a new business, who needs to develop a mobile app, website, and backend, to have a clear understanding of the budget involved.
Improving Estimations with the Risk Driven Method: A Step-by-Step Approach
I want to share with you the Risk Driven Estimation method. It helps me make more accurate estimations and I think it could be useful for you too, whether you are estimating a year-long project or features for the next two weeks. This method requires you to answer some questions before you start thinking about how much time you need to implement something:
Now we will create a table, firstly listing the things you need to do. It will be the Work Item column. One short sentence for each item would be sufficient. Next, add an Owner column for the developer responsible for that particular part of work. It is easier to complete tasks within estimations if you estimated them yourself.
Finally, we need to add how many hours are needed for each item. Of course, we need a column for estimation, perhaps even two columns: Low and High. Low is your (developer) regular estimation when you believe that you know what is required and you can imagine all the steps to implement it.
The High column is different. High is the worst case scenario or pessimistic estimation. You should encourage the developer to think what if…? Eg. for “Get user location”, you should ask: what if user has a disabled location on his smartphone? Perhaps you will need to display some pop-up to ask for permission. What if the user did not allow access to his location? How to manage permissions? What accuracy of location is required for this task? What if determining location will take some time?
Usually, developers think about a smooth and happy path, but we all know how many crossroads, dead ends, and exceptions happen in our applications on production. The High column is a place to predict the worst that can happen. Don’t think about making your PM or client happy with small but hard to deliver estimations. Also, Low and High columns can be in hours, days, or whatever you use.
As you can see, some items have a greater difference between Low and High than others. These are tasks with more uncertainty or in other words — there is a high risk. So let’s add one more column — Risk.
How is risk calculated? There is a formula:
Risk = (High — Low) * (High + Low) / 2
The risk depends not only on how big are the numbers but also how big is the difference. Now it’s easy to see that “Get user location” is much riskier than other tasks. What can you do with such a risky task? There are some solutions; you could divide the task into smaller ones, you can ask for some time to make a research about the problem or maybe you can skip it as it’s not core functionality.
In this example, we will divide “Get user location” into 3 tasks.
Now the estimation runs from 13 to 24 hours. You might think it will be hard to show a client who expects one solid number, but when you describe what Low and High means, then the client can understand the risk and check if it matches the budget. IT has always had a problem with estimations so it is better to know the cost of worst case scenarios before they happen.
Is that it? Of course not. Also in development, we have code reviews, tests, and management. If you look at your Jira/Redmine or other time tracking system you will see that these jobs usually are take up a fraction of the whole implementation. Eg. for one of our projects at Snowdog, Code Review took up 3%, Testing 11% and PM 9% of the total time. So we can add the last column to our table — Factor.
This method is based on Risk Driven Scheduling by Tim James and I have used it at Snowdog to estimate features and projects for about 2 years. It has helped me to deliver better estimations and detect weak/risky points in the scope of work. I encourage you to try it out, maybe you will find it useful too. To make it easier, here is a spreadsheet to get started.
