If you’re moving to agile project management from more traditional project management approaches, estimating is a crucial skill you’ll have to relearn because it’s different in agile PM. This article explains the basics.
In agile PM, the best estimating isn’t done by a lone wolf PM or team lead; it’s handled by the team — developers, testers, analysts, database administrators and architects. The idea is that the team as a group reviews the estimated features from multiple perspectives, and then the feedback from everyone is absorbed and merged into one final and agreed upon estimate.
The value of team estimation delivers many benefits. For example, finding out what others are thinking about can lead to faster maturing as a team by broadening everybody’s understanding and estimating skills. It can also help you get better estimates from the people who will actually be doing the work and have firsthand knowledge of the architecture, code and environments in which they’ll be working. Plus, the process will begin to create a culture of ownership around the estimate, where the team must hold itself accountable.
In spite of the benefits, however, doing team-based estimating is hard. My experience has shown that it will take many rounds of practice before you become truly adept.
Traditional Planning vs. Planning
In traditional project planning you create a high-level estimate during the project initiation phase and then firm it up during the planning cycle. The business analyst usually takes high-level goals or plans from technical teams and converts them into functional specifications.
If the technical resources haven’t undertaken a similar project before, they may have trouble estimating the work by virtue of its complexity or singularity. Also the teams producing the estimates probably won’t estimate the work as if this were the only assignment they had. They also must complete all of the other work activities they’ve been assigned. These elements make the final estimate hard to pin down, which could delay the estimating process.
Then other parts of the organization build time into the schedule to accommodate their own functions, such as packaging and delivery and marketing. At every level, buffers are added to cover contingencies on top of the original estimate so that the deadline (they believe) has a higher chance of being met. Typically, each group might add its own buffers as the plan moves from the technical teams to the project teams and onto the marketing team. By the time the estimate is done, this series of layered buffers muddies the waters when anybody wants to figure out when something can realistically be delivered.
In agile projects, estimation techniques address these potential issues. You do the estimate as an iterative process, where you don’t estimate all the features until you have prioritized what is needed. In agile the phased approach to estimating helps to create clarity and understanding of the features being requested as the project progresses.
If you have ever been involved in a scrum process or some other agile discipline, you’ll know that work for completing deliverables is time-boxed to ensure a focus on delivering value and the immediate priority of features. After each sprint’s delivery, the team re-estimates the remaining requested features, tasks and user stories and prioritizes them again based on the learning accumulated after each sprint.
The agile estimation process usually consists of these stages:
- Review and estimate features in a short, time-boxed exercise during which you estimate feature size, not duration or hours.
- Assign sizing to planned work iterations (sometimes referenced as sprints, but multiple sprints can also exist in an iteration) and then align those with a release plan for key features.
- Disassemble each sprint’s features into the specific tasks needed to build the features and estimate the level of effort to deliver each. Once completed, the tasks are assigned to the appropriate iteration.
- Meet daily or frequently as a team to evaluate and re-estimate the remaining and open tasks during the entire iteration.
Estimating by Hours vs. Story Points
The sizing of tasks or features is a key estimating method in agile. Even though it’s difficult to size tasks or features if a technical team has never done the same kind of work before, there’s something about technical teams that somehow tend to know the sizing or complexity factor.
Using story points is a great way to estimate numerically. Typically, individual tasks should a defined size of effort (work). If you’re on an agile project team using story points, you may set a story point upper limit. For work that is larger than several days, it may be too hard to estimate the work items; or the confidence factor of the estimate will be low, so you would break the work into smaller elements that you can more accurately estimate.
For features not selected, you place them on the top of the backlog. You break anything larger than several days’ effort into smaller estimating tasks that you then prioritize and assign.
Prioritization of features in the backlog helps to keep estimating at a high level of quality. The use of the backlog helps to eliminate rework or delivery of features that the customer may not need — even if the customer originally surfaced them.
Velocity and Burn Down vs. Earned Value
Leveraging past information for future prediction provides the goal of both earned value and agile planning. That goal is accurate prediction of time, work and cost in delivering a project.
Waterfall teams hold lessons-learned sessions, but usually those happen at the end, even though more frequent discussions might be more helpful. Agile PPM teams use “retrospectives” to incorporate insights from past iterations, including the accuracy of their estimates. Many agile tools — such as Version 1 or Jira Software and the Microsoft Project agile template — track story points, a numeric value that helps teams in their reviews and recalibration of estimates.
In agile PM the use of velocity is a predictive means for forecasting delivery. The term “velocity” is used to showcase a predictive measure based on the number of story points, tasks or features that can be completed in a single iteration. While this is as simple as it sounds, it’s also effective because it uses a feedback loop at every iteration to reflect what the team actually achieved in the previous iteration.
The Power of the Team in Agile Estimating
In general, estimates can be very inaccurate. They are subjective and can vary depending on times of the year, people’s moods, or even how much sleep or coffee a person has had. Yet group estimating, coupled with short cycle reviews of the estimates and delivery, provides a true-up process that helps teams to tune and improve their estimates and estimating skills. When applied to a time-phased calendar review for a team, the retrospective tends to average out, regardless of sleep, coffee, mood or experience, giving a predictive velocity indicator that’s helpful for future delivery.
If this sounds complex, the science behind it can be; but the practical application is not. For agile teams, this time-phased review of delivery by points or features can give a surprisingly accurate estimating tool for planning what can be accomplished within future time periods and iterations.
