A good Work Breakdown Structure (WBS) clarifies product costs and shows the real scope of work that lies ahead. Let’s see how our CRO Vladimir Panteleev suggests estimating projects.
Having a startup idea is just the first step. Then you need to validate the problem, pursue product-market fit, and finally begin to develop the actual product.
In many cases, when founders ask their partners to do that, they have just a vague understanding of the scope of work. That leads to unclear budget and cost estimation.
Understand the product origin
To be able to estimate the project you need to understand why it was created in the first place.
There are many vague ideas. Founders don’t know what they want to do with their products. That’s why it’s important to dig into the project and see if it is worthy or not.
After the initial introduction and the first call, the time for the actual proposal comes. You may think that at this stage everybody from the founding team knows everything about the future product, but it’s never the case.
That’s why you need to understand that estimating tasks for sprints isn’t equal to estimating the project in the very beginning. There are different scopes and you need to make initial estimation way faster.
On to the WBS
A work breakdown structure is a format of writing down the scope of your project and all the tasks to do. Simply put, it’s the set of tasks united by a hierarchical structure that helps you to organize your work and navigate all the tasks quickly.
You can do it in Excel, Airtable, or any other service that helps you organize tables and sheets and work with formulas easily. There are plenty of templates on the Internet to choose from.
There is always some top-level element (like epic task) that includes all the low-level ones (like tasks). You can break the features the way you like: by user stories, by front and back development, and so on.
There are no solid rules on how to break things into tasks and features, you can have as many levels of tasks as you want. Still, it’s better not to fancy too many levels, because it will blur your tasks.
Why working with WBS is awesome:
- You can easily calculate all the formulas because everything is automated and you know how much each feature and each epic costs.
- You can easily navigate your scope of work and add things to it smoothly.
- The whole estimation process becomes simple (feature navigation is easy with WBS).
WBS life hacks
- Don’t split your tasks on the frontend and backend.
- It will create too much friction and you won’t be able to tell where to place the mutual tasks and how to connect them. For example, you have a login feature to develop. It consists of backend development and frontend inquiries, but it won’t work without two things being connected. If you split the tasks by the type of development, you need to introduce the third type of task — the connection one. It will make the tree of tasks too complicated.
- To avoid this, it’s easier to split your tasks by user stories.
- If you have similar lists from previous projects, reuse them.
- You need to calculate the estimated budget, not all the precise details of the work. So don’t be afraid if your calculation will not be 100% accurate. Still, be aware not to make big miscalculations. In the end, you’re working with money predictions.
- Decomposition is everything.
- Be critical. If some epics and features can be merged, cut, changed and so on — do it. WBS is created as a technical validation of the solution you’re proposing, not just some random set of numbers.
Creating a WBS
Generally, there are three numbers to consider while creating a WBS — the minimum number of hours to do the task (if everything goes smoothly), the maximum time (if everything goes wrong), and the average one (basically the reality for most of the projects).
All the tasks should have these three parameters to calculate the budget and estimated time for the project. You can also see prices, priorities, phases of the project, and comments when needed. Normally all the features in WBS are located under epics the same way as user journeys go.
All the smaller tasks and common tasks for all the features (for example, localization) can be found at the end of the sheet together with integrations.
You need WBS for every possible scope because it will not only help you to estimate the budget of the project but will also help to demonstrate your work to the founders. Without it, it will be too hard for your customers to navigate the progress.
You don’t need to calculate the whole scope of work and the whole team. It’s ok to calculate only the working hours of the developer to know some average time for the work of other people on the team.
For example, if you know that a developer needs 3 hours to create something, then you can guess that QA will test it in an hour, and so on.
Calculating WBS
First of all, you need to calculate the budget of the project, not the number of sprints. Your goal is to understand the approximate scale of the budget to guide you when talking about the budget with stakeholders.
To do so, calculate the features in working hours. By multiplying it by the rate you can get the budget of the project. In many cases, especially in startups, the speed of calculation is way more important than its accuracy because you need to persuade the founder to agree to your proposal fast.
Don’t be afraid to make a mistake! If you’re not sure of your calculations, ask your colleague or teammate. If the whole team is afraid, take the optimal calculation and multiply it by the number of people worried. Generally, it will give you the correct estimation.
Choose your estimation model X$
There are several ways to calculate your project budget and scope of features.
When you estimate from the top, you’re using the default approach to calculate the big chunks of tasks. For example, you have an onboarding and a big Sign-in feature in it. Using this approach you won’t think about how much time it will take to develop each button in the feature.
You think about how much time the development of the whole feature will take. Generally, such an approach takes hours and the error is big.
If you estimate from the bottom, you decompose the whole project into the smallest chunks and micro-tasks like developing a checkbox “remember me”. Such estimation may take days, but the error is low. Still, such precision costs you too much time.
You can also do your estimation by analog. If you had a similar project before, you can copy your WBS from it. This approach takes minutes and the error is average because the estimation is made according to your previous experience.
Of course, you can calculate the project for fun. Just pick a number from your head and say it out loud — you’ll get an ultra-fast estimation with tons of possibility for error.
Decide how to find your working hours
To calculate how many hours you need to complete each task you can use one of the three types of calculation.
It’s easy to calculate the average between the most optimistic and pessimistic prognosis that you make — you just put in the medium number of hours. Still, it doesn’t look like a realistic scenario.
Generally, it takes more time to complete a task than you thought. So you can go for the Best Guess number which is generally somewhere between average and the most pessimistic ones.
If you need to calculate the most precise numbers, you can use the Three-point estimate method by the formula:
(Optimistic + Pessimistic + 4xBest Guess)/6 = Three-point estimate number
The only con of this method is that you need all three numbers to calculate it and it may take more time than you have.
Bottom line
Even while calculating WBS may seem like struggling in the beginning, it will save you a lot of nerves while speaking with your founders. After all, you’ll have all the necessary estimations to solve their problems.
Just don’t go into too much detail and don’t waste a bunch of time on a precise estimation. Calculate the budget and overall project time quickly and show your expertise and strength.
About the author 🤝
Vladimir Panteleev is the CTO at Paralect — learn more about his journey from project management to R&D and more in this interview: