Once you think about basis of planning in a project what can you think of? Do you consider Work Breakdown Structure (WBS), product backlog, people and resources assigned to the project, their availability or maybe task dependencies? If any of them – you are on the right path, however most tricky and misjudged in project planning may appear effort estimation. Estimating includes lots of traps, estimates can also be a trap itself for Project Manager or Project Team. Do you know where the traps lurk in estimating?


Estimate form its nature – why to estimate?

 Dictionaries are defining estimations as “a rough calculation of the value, number, quantity, or extent of something”1. It may be thought this is something minor, trivial or meaningless in the project. That’s the first trap of estimating. For the Clients, Sponsors, and Management almost all projects start with the question – how much it will cost? What is the funding that is required to deliver the product? You can re-formulate those questions and ask about schedule, people to be hired or how many user stories next sprint is going to cover. To answer it you need to estimate.

Process of estimation can be painful and time-consuming but it’s fundamental for:

  • setting a price affordable for the Client and realistic for delivery team,
  • guiding the Client how much their idea will cost,
  • defining project parameters,
  • setting milestones,
  • planning resources and staffing etc.

You may point out here that sometimes price is not set at the very beginning of the project. You can think of time and material contract in which the scope is not fully set and the Client is paying for time spent, nevertheless reality is that those kind of contracts are usually capped and again we are back to idea of estimation (another trap).

Levels of estimations – what kind of estimate do you need?

Estimations are also about providing proper information regarding a project to certain decision makers. Will the project be profitable? Shall we start the project? Does the Customer want to invest into that endeavor?

Providing detailed estimates to executive management will be almost useless information for them to decide on investment. Managers and Clients need ballpark estimates to determine if this is profitable or manageable. On the other hand Project Manager will look on the detailed estimations to have planned phases, monitor and control the project. Product Owner will need as well more specifics to plan for few weeks and iterations.

Improper precision may be misleading and vain for certain level of stakeholders in certain points in the project – this is next trap of estimating. Remember to match precision to the decision, try to identify decision first and understand what stakeholders’ requirements are. You can utilize ranges of estimates and confidence levels to help Customer or Management in making proper decisions.

Estimating approaches – hourly trap

Selecting the approach for estimations should not be very tough task – you can estimate in hours which is most common to measure work required to complete a task or build certain functionality. It’s straightforward and easy to understand, why to complicate more? Looking on that topic from traps perspective it is turning out that there are much more than one arcane trick hidden behind it.

Each estimate is unique but it always includes guesswork that’s why this is an estimate – meaning assessment not actual cost. If you assess in hours then you think about amount of work that can be done by one person in one hour but the fact is that time is very subjective. Consider, what is more objective in terms of asking how far is from Wroclaw to Warsaw: 3h and 31 minutes or 348 km?

Obviously time will have dependencies related to traffic, mean of transport, skills of the driver, number of stops etc. Time is very subjective – that’s the trap. If you have senior and junior persons in the Team they will complete the same task in different amount of hours.

Additionally, there is phenomenon described by Daniel Kahneman and Amos Tversky – planning fallancy2. People tend to underestimate time required for tasks – we are simply too optimistic. Interesting is that it is appearing no matter of the experience and knowledge of the person once they are estimating for themselves. On top of optimism people assessing time do not account for non-project related work included in the task neither amount of risk, uncertainty and complexity related to its delivery.

Sometimes tasks are also not very clear because they are new or not investigated yet but still estimate is required – then it’s hard to assess the time needed for their completion.

Hourly estimates may lead as well to padding, which is a kind of other extremum comparing to being too optimistic. On top of that hours estimated are commitment – and the clients or stakeholders for sure will track them and ask about inaccuracies between actual cost and estimate.

Estimating approaches – alternatives

Thinking about some alternatives to mitigate this burden – what are the other options?

As Ben Aston is indicating in his article “In the post-waterfall world of agile (…) the alternative is to simply size tasks and get going on a project, see how much you can accomplish and then work out how much you’ll be able to accomplish when you’ve established your velocity”3. The main choice is here the story points method. Story points are also units of measure of effort but such, which includes not only amount of work but also amount of risk, uncertainty and complexity. This is relative way of showing effort – good comparison are here isochrones (showing time) vs. isodistances (showing distance) – maps depicting how far is form Wrocław to Warsaw4. Story points may be based on Fibonacci scale5 or others like T-Shirt sizes or bucket sizes – they may be compared to isodistances. They are a kind of stable indexes that are independent of the skill or experience of the person estimating. It helps to stay flexible in terms of re-planning and do not commit certain time. It sounds as remedy for all hourly estimates traps, nevertheless as everything this method has some disadvantages as well, e.g.:

  • teams may not feel very comfortable to utilize it – they need some education,
  • it may include some kind of padding – inflating story point from 1 to 3 to show better performance,
  • it is not working so well if the team is changeable,
  • it is not showing bottom line directly – story points are not money or time.

All in all there are other alternatives that may fit to the project estimates approach and can eliminate some pitfalls of hourly assessments, e.g.:

  • cycletimes – “total elapsed time to move a unit of work from the beginning to the end of a physical process” 6
  • lead times – “measures the total time it takes for work to move through the value stream, from the moment the work is requested to the time it’s delivered”7
  • throughput – “average number of units processed per time unit. In a Kanban system, examples can include ‘cards per day’, ‘cards per week’, or ‘story points per iteration’.” 7
  • number of items per sprint etc.

Don’t let be trapped in your project

Project Manager can be ensnared in numerous traps but are you deemed on it? Scrum Guide is advising: “Respect the complexity of software development, and don’t let estimation replace the importance of empiricism itself.” Only collaboration and communication can save you from being behind bars of estimations.

It’s not only the advice for software development but each and every project in which Project Manager has to closely work with the Team. Think about what’s working the best for the Team as well as consider which approaches and levels would work well in certain situations.

Utilize best practices with story points and avoid negative phenomena as padding or planning fallancy. “Measure, compare, reflect”, collaborate and communicate – this is a universal key to most of the traps.

If you think now that mentioned challenges are the only traps of estimating you are way off beam. Estimation levels and estimation approaches tricks are only some that are hidden in the bigger exit room of the project. You need to unleash from them in given time, budget and/or scope agreed with the Customer or Sponsor. Stay tuned some more keys opening traps of estimations coming soon.

Sources:

  1. https://en.oxforddictionaries.com/definition/estimation
  2. https://en.wikipedia.org/wiki/Planning_fallacy
  3. https://thedigitalprojectmanager.com/project-budget-cost-estimation-guide/
  4. https://www.iso4app.net/
  5. https://en.wikipedia.org/wiki/Fibonacci_scale_(agile)
  6. https://www.isixsigma.com/dictionary/cycle-time/
  7. https://leankit.com/learn/kanban/lean-flow-metrics/