Inaccurate estimates are among the most popular project management challenges. When starting a new IT project, you want to know two things: how long it is going to take and how much it is going to cost. To answer these questions, you must estimate the projects you’re about to run. There is no magic rule that says that Project X takes 12 weeks and costs $150,000. Or a Y-like website takes 10 weeks to develop and costs $100,000.
What you will learn from this article:
• How do project managers prepare for cost estimation in project management?
• Which estimation techniques are useful for project estimation?
• How does planning take to prepare yourself to estimate costs with formulas?
You can’t assess a project’s timeline or cost without thorough estimation, even if the project’s scope is very similar to what you’ve done before. Yet, things get worse: Estimation will never give you a 100% accurate answer to these questions as well. So, why do we estimate? Because it’s the only way to make assumptions about the project’s timeline and budget, the workload, and the resources needed to deliver it.
Estimating the project, you’re also able to schedule employees with the right experience and skillset. What you can do about it is to use methodologies and techniques that’ll let you estimate with the maximum accuracy possible. Here’s how to use the Agile methodology and Planning Poker technique to create meaningful estimates of your project.
James Grenning developed the planning poker session known for its strategy in 2002 called Scrum poker. During the early 1950s, his estimation method, Wide band Delphi, was too time-consuming and had other limitations. In Grenning’s case, the poker plan was originally about addressing a problem in which the players were too enthused and overly focused to win. Mike Cohn, founder of Agile alliances and Scrum alliances, later used this technique for an article titled Agile Estimation and Planning.
Starting a successful project relies mostly on how well you understand what it is actually about. That includes:
• Understanding the expectations of your client
• Understanding the objectives of the project and its main goal
• Creating a list of required features
Once you have gotten through the client’s brief and have as much information about the project requirements as possible, you’re able to list all the features and pass them to your team.
In order to do so, create a product backlog that consists of all the to-do features. You can then prioritize them, evaluate their complexity, and estimate how long it will take to complete them. A proper product backlog should consist of:
• User stories — describe the actions that users can take at every step of using the product
• Acceptance criteria — list the items needed for a story to be completed
• Story points — estimate the amount of work, risks, and complexity in relative point value
• Tasks for user stories — list the tasks needed to be done in order to deliver a user story
It is crucial to involve the development team in creating and prioritizing the product backlog to ensure accurate and realistic assessments.
With a list of features ready, assign priority to each one of them. You can use the MoSCoW analysis method to sort them as:
• Must have
• Should have
• Could have
• Won’t have
Developing a project, focus on things you have to deliver in the first place. Building an MVP gives you the possibility to test hypotheses about your idea before completing the whole project, show it to stakeholders or beta users, and collect feedback important for further development of the rest of the features.
Assigning priority can also help you with estimating the project. As you focus on the main features and the ones that you need to do first, you can make more accurate assumptions about their estimated completion. For “could have” features, you can start with a ballpark estimation, as they are further in the development process and a lot can change by the time your team gets to them (and if your team gets to them, as after collecting feedback about your MVP you can pivot and not include all of the initially planned functionalities).
It is important, however, to estimate all the features, regardless of their priority (except the “won’t have” ones, of course), as you want to get an overview of the whole project at once. And as you get to the next stages of the project, you can re-evaluate the scope of work, to make sure your estimates remain accurate.
Now that you have your product backlog completed, it’s time to estimate each one of its items. To do so, we use story points. They are units Agile teams use to evaluate the work needed to complete each item from the backlog. Story points help to assign relative value to the product backlog items. They are not related to time and can bear different values to different teams, so they don’t carry the emotional value. Thus, chances are that team members won’t pad the estimates just to be safe. Planning Poker helps software teams to plan workflows and improve project delivery rates.
Using story points, a team can estimate:
Planning Session is one of the gross-level estimation techniques, using a modified version of the Fibonacci sequence: 1, 2, 3, 5, 8, 13, 20, 40, 100. To estimate items from the product backlog, team members get the same sets of planning poker cards with numbers on them. Then, after a brief introduction of the product backlog item by the Product Owner (who doesn’t vote) and the discussion, they privately pick the card with the number of story points they consider relevant to the amount of work required to complete this item and reveal them at the same time.
If the numbers differ, team members discuss why they’ve chosen such an amount of story points, and then vote again. This is part of the planning poker process, a consensus-based estimation method used in Agile to estimate effort for user stories. They do so till they reach a consensus and then move on to the next item from the product backlog. And if the number agreed on is high, let’s say 20, 40, or higher, it means that a story may require too much work for one sprint and may need to be broken down into smaller tasks. Ideally, the presentation of the item, discussion, and voting should take around two minutes, which allows for estimating the whole backlog in a short amount of time. But as the point here is to estimate the whole backlog at once, take your time, and don’t worry when some stories take a little bit longer to assess.
Team velocity shows you what is the pace of the project development. It helps with understanding two things:
• What amount of work your team is able to do in one sprint
• What is the predicted date of finishing the whole scope, assuming that it’s fixed
The velocity is different for every team. You can assess it after the initial iterations when your team has already worked on some features. For example, if you’ve included four product backlog items in the first iteration for a total number of 20 story points, and the team finished three of them equaling 15 story points, this is your team’s current velocity. Remember that only completed items count. Even if they’d managed to start the fourth item but haven’t finished it, it doesn’t count.
The scrum master plays a crucial role in facilitating the estimation process and ensuring accurate assessments during these sessions.
After negotiating story points and assessing team velocity, you’re able to determine the project’s schedule. To do so, add up team velocity from the last three iterations and divide it by three. For example, if the velocity from those iterations was 20, 23, and 17, the average velocity would equal approximately 20 points. If the total amount of work had been estimated at 100 story points, then, with the average velocity of 20 points, it would take 5 iterations to complete the project. Assuming that one iteration takes two weeks, you should deliver the project in 10 weeks.
To determine the budget of your project, you can use this basic formula: (total Story Points / Velocity * team hours per sprint) + non-labor costs = estimated budget. Having a total number of story points divided by the average velocity, multiply the number of sprints by 40 hours per week per team member to get your labor cost. Then add the non-labor costs like capital costs, equipment costs, maintenance costs, training costs, etc. For example, we have a project estimated at 100 story points and our team’s average velocity is 20. Assigning 5 people team to the project with $50 hourly rates, the team hours per sprint are worth $20,000 and $100,000 for 5 sprints. With a hypothetical non-labor cost of $50,000, the estimated budget for our project would be $150,000. Considering the confidence intervals on exemplary levels of 80–120%, the reported range of our budget is now $120,000 to $180,000.
Remember that no estimation is 100% accurate. It’s best to re-estimate your project every few iterations, as things, like resource availability, team velocity, or project’s scope, may change over time. Re-estimating, you’re making sure that your estimate is up to date. Using time tracking and resource scheduling software will also help you manage your team’s availability and reassign them if needed. With the right techniques and tools, you can make your estimates more reliable and better plan your next project.
Accurate project estimation is crucial for successful project management. By understanding the expectations and objectives, creating a detailed product backlog, prioritizing features, and using techniques like story points and Planning Poker, you can improve the accuracy of your estimates. Regular re-estimation and using tools for time tracking and resource management further enhance the reliability of your project timelines and budgets. By following these practices, you can overcome the challenges of inaccurate estimates and ensure better project outcomes.
Use the Planning Poker estimation technique with ease
Check the reason why our resource management software is chosen by project managers from Hill-Knowlton or Stormind Games
Resource calendar (or project management calendar, or project planning calendar, resource planning software) allows you to plan and manage and allocate resources more effectively and efficiently – especially if Microsoft Excel had a leading role in your...
What’s the ultimate goal of project managers? Delivering their projects successfully. PMs themselves admit that this doesn’t happen very often: according to the latest Pulse of the Profession survey, less than 60% of projects are completed either...
Capacity management is a strategy utilized by businesses to make the best use of production efficiency with respect to the demand for a service or a product. The eventual goal of capacity management is to: Identify and...