Get yourself a coffee. This is probably my longest blog. It's been cathartic, but it might help others estimate their projects.
At the heart of every project lies a set of estimations - a roadmap that guides our teams to the end goal. As we embark on a new delivery, these estimations act as signposts along an ever-evolving path. One familiar pitfall project managers face is the underestimation of the effort required. Here, I want to delve into the nature of estimation, its challenges, and strategies to mitigate related risks.
As the term suggests, estimates are educated guesses about what lies ahead in the project journey. In the beginning, these guesses can be wide off the mark. However, as we venture further, the fog of uncertainty should begin to lift, making way for increasingly accurate estimations. Our estimations should mirror the "cone of uncertainty", a concept illustrated by Steve McConnell in his book, "Software Estimation: Demystifying the Black Art". As the project progresses, the cone narrows, symbolising a decrease in the estimation uncertainty.
So, giving estimates within a range rather than a single figure can combat underestimation. The common practice of providing an overly optimistic figure can set unrealistic expectations and set a project up for failure. I firmly believe in tri-estimation: providing a best-case, worst-case, and most likely scenario. This method gives a holistic view of the situation, offering a reasonable buffer for uncertainties. I'd go further than this in many projects, particularly the longer ones, and say that publishing these figures clearly in your reports is crucial. I've had pushback on this over the years, with people only wanting to publish 'the most likely' estimate, which in my opinion, is dangerous as it misses context and will almost always need constant adjustment.
In the early stages of a project, it's easy to get bogged down with creating perfect estimates. People often see it as handing the management team a stick to be beaten with if they fail to adhere to the early assessment. But sometimes, we must put a stake in the ground and make a 'Wild Arsed Guess (WAG)'. Many people are reluctant to give anything without analysing, workshopping, discussing, pro-types, etc. They get struck down by analysis paralysis and can't provide a rough order of magnitude (ROM) estimate. But these are often needed to understand a project's viability and likely costs during the feasibility stages. Teasing them out of teams can be painful but necessary.
I'd suggest, in these instances timeboxing the duration for such estimates (e.g. having a short workshop to discuss the likely resources and time). However, it's crucial to remember not to hinge delivery upon these early, rough estimates. Senior management often interprets estimates as confirmed delivery dates, ignoring the caveats that come with them. If someone says we are tracking 6th April, that's their takeaway. That's all they hear, "6th April". Anything less will be considered overdue. When communicating estimates, it is essential to articulate the uncertainties and variables affecting the timeline. Nobody wants to be perceived as a doomsayer, but reporting overly optimistic timescales, which you then push out week by week, is the weakest form of project management.
Let's talk about tools. Development estimate tools can be instrumental in tracking and predicting project progress. A well-executed tool can be a project manager's best ally.
My Favourite: Burndown Charts
Consider the burndown chart, a staple in agile methodologies. This simple yet powerful graph shows work left to do versus time. It visually represents progress, helping teams adjust their pace and strategies to meet their goals. Despite being associated with agile development, burndown charts can also be adapted to other projects or situations, making them a versatile tool in a project manager's toolbox.
A burndown chart is a visual tool used predominantly in agile project management to illustrate the amount of work remaining in a project against time. The x-axis typically represents time (in days, weeks, or sprints), and the y-axis represents the work left to complete, usually measured in hours or story points. At the start of the project, a line is drawn from the top left corner (representing the total work to be done) down to the right, indicating the expected completion rate. As tasks are completed, they are marked off, creating a new line that 'burns down' towards the x-axis. The comparison between the actual progress and ideal lines visually represents whether the project is on track. If the project is ahead of schedule, the actual line will be below the ideal line; if it's behind schedule, it will be above. The burndown chart's real-time update capability allows teams to react and adjust their pace or strategies as necessary promptly. It does depend on getting an early estimate on epics/tasks (often in "story points") and then the pace (or 'velocity') of the team (i.e. how many story points they can get through in a period). Teams can be reluctant to do this type of estimating as it can be heavy on the effort up front.
Ah, you say, "Estimating the effort of a project upfront is waterfall, not agile!" Ah, I say, "Tell me how you will estimate the delivery of the entire project then?" At some point, the estimates must move to something based on evidence and calculations. We need that. Estimate the epics (big ticket items) for the project as a whole, and then estimate the user stories for the sprint you are entering. That way, you can have a sprint burndown and a project burndown.
Methods of Estimation
However, just like any other tool, the effectiveness of a burndown chart lies in its execution. To accurately reflect a project's status, the data needs to be there, and it's an iterative cycle; back to the first point about the 'cone of uncertainty'.
In Mike Cohn's book called 'Agile Estimating and Planning,' he gives several methods of estimation;
Story Points: Cohn explains that estimating with story points is a beneficial and efficient technique. A story point is a measure of effort required to implement a user story, which is an informal description of a feature from an end-user perspective. In story point estimation, the relative size of a user story is compared to other user stories, and points are assigned accordingly. It is a comparative metric and doesn't correlate to a specific time duration, like hours or days.
Ideal Days: Cohn introduces the concept of ideal days for estimation. Ideal days represent the time something would take to develop without interruptions. Thus they represent a "perfect" or "ideal" development environment. This method can be more intuitive for some teams, as it's based on time. Still, it must be adjusted according to the team's efficiency and inevitable interruptions in real-world work environments.
Planning Poker: This is a consensus-based technique for estimating the effort or size of user stories in Scrum. Each team member is given a set of cards (usually online) with different numbers corresponding to the Fibonacci sequence. For each user story, team members privately select a card representing their estimated effort required and then simultaneously reveal their cards. This leads to discussion and, ultimately, consensus on an estimate.
Affinity Estimating: In this technique, user stories are grouped by their similarities or 'affinities.' Teams compare a new user story with already-sized stories and place it in the appropriate group. It is handy for estimating a large number of user stories quickly.
T-Shirt Sizing: Here, user stories are assigned sizes that correspond to t-shirt sizes (XS, S, M, L, XL). Alternatively, a Fibonacci sequence is used (e.g. 1,2,3,5,8). It's a less precise but quick method, often used in the early stages of a project and one I've used many times.
Cohn emphasises that no estimation technique is universally better than others. The choice depends on the team's preference, the project specifics, and the level of precision required. All these techniques aim to break the complexity of tasks into manageable, estimable units. They should be refined as the project progresses and the team gains more knowledge and insights.
Don't Forget The Testing
While here, I want to ensure this thought is captured too.
Don't underestimate the testing phase.
Some industry experts propose that testing can take up 25% to 50% of the total project effort. For instance, in "The Art of Software Testing" by Glenford J. Myers, Corey Sandler, and Tom Badgett, they suggest that, in many cases, the ratio might lean more towards a 1:1 ratio for development to testing, especially for highly critical or complex systems. An Agile cycle doesn't stop the need for a thorough testing phase(s) at the project's back end.
If you're outsourcing your development, you'll still need a hefty QA phase. I'm used to external development organisations shovelling crap over the fence and expecting UAT to pick up on the faults. I could write a whole article on just that. Maybe I will…
Ring Fence Your Resource
One final thought; estimates are for nothing if the resources aren't ring-fenced against outside interruption. Suppose your team is working on other things simultaneously, such as delivering bugs and fixes while developing new features. Your estimates will likely get blown out of the water in that case. Sometimes this is unavoidable, in which case you need to estimate the amount of time for that external 'noise', but the better approach is ring-fencing resources. The more critical the delivery, the more I'd ring-fence the resource.
In conclusion, project estimation is fraught with potential pitfalls, and underestimation is a common yet dangerous misstep. By utilising a dynamic, range-based approach to estimation, recognising the value of early-stage 'WAGs', improving the communication of uncertainties, and effectively employing tools such as burndown charts, we can mitigate these risks, setting our projects up for success.
Further Reading:
McConnell, Steve. "Software Estimation: Demystifying the Black Art". Microsoft Press, 2006.
Lederer, Albert L., and Jayesh Prasad. "Nine management guidelines for better cost estimating." Communications of the ACM, 1992.
Cohn, M. (2005). Agile Estimating and Planning. Prentice Hall Professional Technical Reference.
Comments