Agile meets Project Benchmark Estimation. Say goodbye to cost overruns. #projectestimation #agilemethodology
Project estimation is a crucial skill for any project manager, especially in agile projects where changes and uncertainties are not only common, they are invited.
I sat down with my friend, Loren Absher and discussed Agile and estimating Projects. Thanks to Loren for providing his insights and guidance.
Agile delivery works with set resources, set time, and variable scope. Traditional projects work with set scope, set time, and variable resources. Businesses like to know exactly what they are buying; there are standard enterprise budget planning exercises and business cases all based on knowing exactly what will be received and when. This approach clashes with the developers who are engaged in a creative activity where they are figuring things out as they progress and every time there is a review something changes. Long gone are the thousand page requirement documents and the accompanying myth that if the requirements document was comprehensive enough then a company could have that assurance.
Are the business units going to operate differently and just open up funding to a project and see what happens? Surely not. Are developers going to suddenly know all the changes that will be requested every time something is reviewed and all of the tech debt they are going to stumble into on a large project? Again, not a possibility.
This central tension is at the heart of what makes project estimation in an Agile delivery environment so difficult. The good news though, is that there are some methods and best practices. But first, let’s make sure we’re talking about the same Agile.
Agile Planning is normally discussed in terms of the next two-week sprint. This form of agile is not the Agile we are talking about. We are talking about large complex projects that need to be delivered on time and on budget for the business unit to be able to approve it. We are talking about strategically important projects that will impact the overall direction of the enterprise. Those requirements combined with Agile delivery is where the tension comes through and the project estimation can make or break the ability to hit overall corporate goals.
Haven’t Scaled Agile frameworks resolved this?
In short, no. Many frameworks that have been developed to scale Agile delivery (e.g., LeSS, SoS, DA, and SAFe), but even where they have a methodology to align, the rest of the enterprise seldom adopts it so it remains an internal IT planning technique.
What about PI Planning and team velocity?
Methodologies like SAFe use techniques such as the Program Increment (PI) Planning Ceremony to provide the goals, and identify dependencies, risks, and deliverables for the next program increment which is a timebox of eight to twelve weeks. During this Program Increment, the Agile team via the Agile Release Train provides working, tested software and systems.
During PI Planning, all the development teams (frequently called pods) agree on the estimated size of each story, frequently using ‘story points’, and then load it into Sprints. Sprints are loaded to capacity using a ‘velocity’ metric to ensure the pod can complete the work within the Sprint. Sprints are good for figuring out the details of the next PI and managing them.
The challenge is that in reality, by the time everyone has met, scope, budget, and timeline has often already been set. The project estimation issue that inhibits delivery has already happened, and they have estimated for much more than a single PI.
So how does an enterprise get high quality estimates for complex projects?
The first rule of good estimation in Agile is to break the project down into small enough chunks and define them well enough to estimate. What ‘enough’ means depends on the data, methods available to the enterprise doing the estimation, and the level of confidence required by the funding decision makers. It also depends on if the project is going to be delivered with internal resources, an external provider, or a blend.
Once the project is broken down into chunks, what estimation method should be used?
Several estimation methodologies exists each with its own level of accuracy. Whether Agile or Waterfall or some other type of project, estimation methods usually center on one of the following methodologies:
- Expert judgment: This method relies on the experience and intuition of experts who have worked on similar projects before. Expert judgment can be useful for quick and rough estimates, but it can also be subjective and biased by personal opinions or preferences. Many organizations use this method for budgeting and validation leading to potentially disastrous downstream effects on project budgets. The “been there, done that” doesn’t always work out as planned.
- Analogous estimation: This method uses historical data from previous projects that are similar in nature and scope to the current one. Analogous estimation is one of the best ways to get early budget estimates if there is a reliable data source that has the outcomes from analogous projects. The lack of accurate or updated data is normally the achilieese heel of the technique as enterprises often do not create or maintain the necessary data set so the projects used for estimation are not analogous.
- Parametric estimation: This method uses mathematical models and formulas to calculate estimates based on various parameters and factors that affect the project. Parametric estimation can provide more precise and objective estimates than analogous estimation, but it requires a lot of data and analysis to build and validate the models. Most organizations do not have the data to support the analysis, and therefore, this method is a non-starter for most organizations.
- Top-down estimation: This method starts with a global estimate of the entire project, based on high-level assumptions and constraints. Then, the estimate is refined and distributed among the lower-level units (such as phases or deliverables). Top-down estimation can provide more consistent and aligned estimates than bottom-up estimation, but it can also be too optimistic or pessimistic depending on the initial assumptions. This method is highly dependent upon having the right assumptions which are also problematic for the early Agile projects.
- Bottom-up estimation: This method breaks down the project into smaller and more manageable units (such as tasks or features) and estimates each unit individually. Then, the estimates are aggregated to get the total estimate for the project. Bottom-up estimation can provide more detailed and realistic estimates than parametric estimation, but it can also be time-consuming and complex to perform. For Agile projects, a bottom-up estimate is highly unlikely to be available during budgeting as the tasks have not been defined until the planning ceremony.
Let’s review some of the benefits and challenges of project estimation in agile projects and share some tips and tools to help you improve your estimation skills and optimize the cost of your project.
Benefits of project estimation in Agile projects
Project estimation in Agile projects can bring many benefits, such as:
1. Sharpening the description of the desired business value from the project — the whole reason to deliver in an agile manner is to focus on delivering the business value not a designed widget, only by fully defining that can the project be solutioned correctly
2. Frequent checks with the business funders if the value they will gain matches the increasingly specific estimations so there are fewer surprises late in the process and the effort required for detailed solutioning can be avoided early on
3. Transparency around what is know and what is not yet known and how that might impact the project cost or timing.
4. Increasing customer satisfaction and value delivery by prioritizing features and delivering them incrementally on budget
5. Improving communication and collaboration among stakeholders, team members, and customers
6. Boosting team morale and motivation by setting achievable goals and celebrating successes
Challenges of project estimation in agile projects
How many times have you heard?,
“We need to figure out what we are building before we can do an estimate of the effort.”
Unlike the Winchester House[1] which was a 36 year construction project to build a house, an agile project should be flexible (the agile part) but also controlled and managed to plan however short the plan.
Agile projects are essentially a series of very small, highly focused development projects each of which can be validated for effort and cost.
The challenge has always been, “You’ll delay the progress by doing a more accurate estimate.” If you estimate as you go, then there is no delay. Using ISG’s guiding principle around project estimation, control and performance management (Forecast, Validate, Refine, Execute, Review, and Adjust), the act of forecasting and validation are constantly refined and matched against team execution. This ongoing Agile increment planning validation becomes the meter by which the team adheres to budgets and adjusts the pod velocity for future planning.
Other challenges with agile project estimates include:
- Dealing with changing requirements and scope creep — agile delivery can easily handle these but not the project estimates
- Balancing effort required to get an estimate and speed needed to make a budgeting decision
- Estimating non-functional requirements and technical debt
- Accounting for human factors such as skills, experience, availability, and productivity
[1] Winchester House Construction — a 36 Year Project Welcome to the Winchester Mystery House® — Winchester Mystery House
Bottom-line
Project estimation is an essential part of agile project management that can help you optimize the cost of your project. By using relative project benchmark estimation techniques, breaking down tasks, involving the team, using historical data, using a range of estimates, updating estimates frequently, and using tools to track and forecast your project performance, you can improve your estimation skills and deliver a cost optimized project.