For estimating to be useful when planning a project, estimates need to closely reflect the reality of what is ahead.
Whenever I ask people to estimate how long tasks will take, the default is almost always in days or hours. However, estimating in days ends up with less useful information than estimating in more abstract scope buckets, such as story points.
What’s wrong with days?!
Using days for estimates works well with small, well-known tasks executed by a single user. They become less useful when you have a larger task to estimate and need to involve more people. Larger tasks need to be broken up into sub-tasks and assigned to other team members. While it is possible to ask every person that would be involved in a task “how long it would take”, each person may use a different assumption.
Splitting all tasks into subtasks is time consuming and not realistic for large projects. Furthermore, getting input from every team member on every task is expensive. If you rely on a single team member to provide an estimate of a task, you often will have some subtasks estimated poorly or even completely ignored. For example, if you ask a development team member the time to implement a new feature, you may get the amount of development time needed, but completely overlook the amount of requirements gathering, designer work, testing, user acceptance feedback, and rework.
What if I convert days to “actual days”?
Using the same unit in a raw and processed format is confusing. It also tends to bias the scoping of the work toward those estimates. Now you are stuck having to convert each individual team member’s estimates to actual-days, which will have a different conversion ratio depending on the developer. Keeping track of these ratios, which can also change over time, will lead to inaccurate estimates. Furthermore, the person making the estimate may not be the one implementing the feature. You will need an additional ratio to convert back to the actual developer, who may have a different level of productivity than the other developers.
If not days, what should I use?
I prefer using story points. Story points are an abstract measurement of relative effort. A feature that is “two story points” is roughly twice as much effort as a feature that is “one story point”. While developers have differing opinions on the actual amount of effort a task takes, it’s easier to come to consensus on relative effort of different features and how they compare.
What good are points if I can’t use it to plan in days?
Days are good points of estimation where there is a low degree of error. Any task that can be handled by a single person and can be compared to previous experiences will fall into this category. However, when you get into larger tasks that require more coordination between multiple people, days are harder to estimate. How do you account for other people’s time? Do you truly understand the amount of effort others will need to spend? There is a tendency to underestimate the effort others need to put forth on a task. Different people also have different definitions of completing a task. One developer may only look at the development of a task, while a PM may consider the time to solicit feedback and rework any parts that need changed.
But how are points actually useful? I can’t tell a client/my boss the project costs 570 points.
Measure how long it takes for a team to complete tasks, and see what the velocity of finishing tasks is. Different teams will have different velocities. However, if you have background information for your team, you can look at what they have achieved in the past and use that as a basis to convert points to actual cost.
How do I standardize points?
Since points are relative, there is no universal scale. Each team may operate with a different standard of points for effort. However, if you must compare between teams, finding a few equivalent stories at various levels can serve as a conversation factor.
How do you adjust the plan based on previous data?
As a project is in progress, you can adjust these projections based on real data and make choices to increase or decrease scope, team size, cost, timeline, and etcetera.
Since estimates in days are never true days anyway, avoid the trap! Estimate effort and collect real data to determine velocity so that you can properly adjust your project. Your estimates will become more accurate allowing your project to become more successful.