The Estimation Is Always The Fun Part Of The Project
Going through the different types of estimation methods and calculating the effort
Hey Everyone 🚀,
I am Artur and welcome to my weekly newsletter. I am focusing on topics like Project Management, Innovation, Leadership, and a bit of Entrepreneurship. I am always open to suggestions for new topics. Feel free to reach me on Substack and share my newsletter if it helps you in any way.
The process of estimation is always fun, especially with developers who are doing it for the first time in a structured way. In the past, I am been always surprised by the difficulty that some developers (even with some professional experience), presented to me when asked to estimate a set of requirements. I would assume I am not the only PM in the entire world to ask for estimations to a Development team, but it seems the number of projects and companies doing structured, streamlined, and even meticulous estimations, are few to be found. Even the most senior developers lack some basic knowledge of how to perform estimations and manage their risk.
Want to send a special thanks to
for their publication below which triggered the idea to write my thoughts about the topic.
The estimations process is directly connected with the methodology that you are using, on both Agile or Waterfall practices. However, the overall requirements are the same:
Have the requirements listed or described in clear language understandable by the team.
The right level of information enables the team to provide a metric.
The activities are divided in a way that the Team can more easily predict the effort.
While checking what our colleagues are saying on PMI, I ran across the diagram below which provides an interesting insight into the process of estimation:
Initially, there are 3 levels of estimation but typically we only heard about two of them:
High-level Estimation: Where the literature calls it as Rough Order of Magnitude Estimate (Expected -25 percent to +75 percent accuracy), when based on Expert Opinion or from Compared Analysis a project or deliverable is guessed to cost a given amount of effort. And the wording is correct: Guessed. Typically this estimation is only to have an idea of which route to follow on a strategy or to highly assess the feasibility based on our resources.
Mid-Level Estimation: Estimation with some work done and some of the requirements are analyzed to understand feasibility or risks. This is typically known as a Budget Estimate (Expected -10 percent and +25 percent accuracy) and is for more supported decision-making or setting the groundwork or budget to start a given project.
Detail Estimation: Where experts go through every bit of requirements and estimate the effort required for its realization. The literature defines this level as a Definitive Estimate (Expected -5% to +10% accuracy) and is where this post will concentrate the most focus.
For the detail estimation process itself, there are several techniques that a Project Manager could adopt, but fundamentally it’s needed both Historical data and Expert judgment. Lacking any of these two variables the level of incertitude and accuracy will drop significantly. Project Management in IT is all about Knowledge Management and eventually, some POCs or tests need to be made for high-uncertainty projects. Rolling wave planning can offer good tools for that, but uncertainty sometimes is misjudged as a lack of methodology.
But to increase the quality of the estimations, the size of what is being estimated needs to be correct. There is no point in estimating a requirement alone that gives 20 days of effort. The level of accuracy is low and no Expert can predict all the risks and issues that may happen. It’s why the Agile methodologies advise breaking the requirements into smaller pieces that can be more easily managed. This is something a Project Manager should pay attention to because not all Developers are experts on estimations. To be honest it is not their fault simply because there are too many projects poorly managed and low-quality estimations taken as accurate. Unfortunately, the Team working on those projects has little resources and knowledge to increase their process.
The most famous techniques for Agile methodology are the T-Shirt Sizing and the Fibonacci Sequence. Check the Agile Estimation Techniques for an overview. Fundamentally both techniques arrive at the same conclusion: On a given size of work item the effort should be an amount of size. Below is a table that can help you visualize (Again check the post above from Practical Project Management where Edgar goes into detail and gives his insight on both estimation techniques):
Notice that I don’t show anything bigger from L or 5 points. Not because the techniques don’t have more values available, but I strongly advocate that once you have a ticket or set of requirements bigger than shown in the table above, you should cut it into smaller pieces.
Why?
The bigger the subject to be estimated the harder it is to be accurate.
Even if estimated by an Expert is difficult to see all the risks and constraints of a work that surpasses a given amount of effort. It stops being an estimate and turns into a highly educated guess game.
If needed to split a work item between two or more developers, is easier to split it into more atomic items which have a concentrated scope. Prevents a lot of overlapping between developers.
A Team Member can easily pick up smaller items if is interrupted midway.
A popular question is in terms of planning: How can a Project Manager translate the points or sizes into actual planning?
This question depends on the methodology. For Scrum is easy, since along the journey or sprints you know how many points your team can deliver each cycle, and the more mature the team becomes, the more predictable it becomes.
For Kanban, you might resort to old-fashioned planning. Based on historical data you can see how much time the team spent on XS, S, M, and L tickets. Once that average is taken from the board or other measure you have at hand, an Gantt graph or planning can be produced.
Notice the output of an estimation is not the effort alone, but also the Risks and constraints that a given task is subject to. While preparing a project planning or a proposal of any kind, those risks need to be part and provisioned on a planning. On my Teams, I say the Risks are more than a slide on a PowerPoint presentation. They need to be provisioned for the sake of accuracy. Provisioned means the risks also need to be estimated and taken into account in planning with a proper likelihood and criticality analysis.
Another output is the Assumptions. For a task to cost an amount of effort is assumed a set of events or requirements is present already. What are the preconditions that make that estimation true? Developers may have a high degree of difficulty understanding this part unless the risk is so evident they might start to refuse to estimate an effort due to uncertainty. In these cases, the item can be too big and as with all big problems, it might need to be cut into smaller more manageable pieces. Or the risk is too high and for the effort to be accurate, it needs a set of conditions which are the plain estimation assumptions.
As you can see the effort is not the only output of an estimation process. Is a rich ground to get data about the Risks and conditions your project needs to go through. Unfortunately, this phase is rushed in so many corporations for the sake of delivery and surprisingly the planning or expectation of a delivery can be off for a significant period purely due to lack of method. As a Project Manager, you should guarantee the quality of the data the decisions are based upon, to increase the accuracy and quality of the deliverables. A bad effort estimation can produce erroneous planning, which requires work, which decreases the quality and can significantly defraud expectations on all levels.
As a final note, I want to shout out to who was kind enough to recommend my newsletter. Recently I have been investigating ways to improve the quality of my project’s UATs and naturally, I was inclined to his post below. Have a look if you fancy improving the test phase.
Cheers,
Artur
Thank you very much for the mention, Artur!
Great post, and the insights on how the output of estimation also includes risks and assumptions is very interesting. It's something that often stays within the realm of development and doesn't scale up to the project level.