Effective Ways to Manage Cost in Agile Project Management

Effective Ways to Manage Cost in Agile Project Management

Have you ever tried to make dinner for people with two very different tastes? That’s a delicate tightrope to walk.

Managing costs on an agile team can feel similar. Between the team and the leadership, it’s like you’re trying to appeal to two very different palates.

First there’s the preferences of leadership (and accounting). Particularly when the risk-tolerance is low, these people want to see all costs up front. Then, there’s the agile team, who is committed to a process of pivoting and adjusting. They cannot plan for every deliverable and cost at the onset.

Even though agile doesn’t provide the certainty of waterfall, it is possible to develop ballpark estimates of a project’s overall cost.

Let’s look at how to approach managing costs for an agile project. But first, let’s clarify when and why the agile method benefits the bottom line in the first place.

Part I: Determining When to Use the Agile Method

In the interest of security, peace of mind, and risk aversion, most company leaders like a detailed project plan. They feel much better when everything is clearly laid out on a gantt chart at the very beginning. Carrying out the project essentially means pressing “go” and having everyone follow a clearly-marked path.

However, this sort of detailed planning doesn’t always yield a successful product, and so it may not ultimately serve the company’s bottom line.

Let’s look at what characteristics make a product better suited to an adaptive approach over a predictive approach, and then focus on how to look at budgets and costs with adaptive project management.

What Signals an Agile Approach?

Some projects have huge up-front costs. At other times, it’s hugely expensive to make changes to a project that is already underway.

Take an airport runway, for example. If a team completes the entire runway, and then afterwards decides it needs to be shifted by several degrees, then they’re looking at a bill twice what they initially estimated.

Building a car is similar. When the team sets out to start manufacturing each part and assembling them together, it doesn’t have a lot of space for alterations. If, say, the team wants to lengthen the seats, then it means they’ll probably also have to adjust the chassis, which would be hugely expensive. All the details need to be settled beforehand.

In scenarios such as these, it’s critical to do a thorough job of researching and planning at the very beginning. This is where a more structured waterfall approach is the smartest route for protecting the business’ bottom line.

However, not all products have the same characteristics. Take software, for example. Ripping into code and making changes does cost something, but it’s only a fraction of the project’s overall budget. So having to scrap some code and start over isn’t a big deal at all. It’s par for the course, really.

Clothing design is similar. Oftentimes a designer can create a piece of clothing, then test it out on a customer for feedback, and make several changes and alterations at no significant cost.

These are critical differences in the nature of production processes. Each entails approaching a project from a completely different point of view. When changes can be made easily and without a lot of effort, it means that everything needn’t be planned from the start. In fact, as any agile enthusiast will tell you, it’s oftentimes better that it isn’t. Over-planning and then creating a product in a black box may result in something that customers won’t use. Then all of the team’s time and money is completely wasted.

We’ve witnessed plenty of times when companies haven’t taken an adaptive approach when it might have—to its dismay. Take some of Apple’s product failures back in the 90s, such as the round mouse pad that was too small and whose cord was too short, making it impossible to use. Or its game station, Pippin, that tried to do way too much without excelling at any one thing. Had they designed these products in increments, testing them on the customer, then pivoting and adjusting before the final release, some of these obvious kinks would have been worked out.

Agile entails backtracking: tearing code apart and starting over. In order to work with the agile process, it’s necessary for leadership to have some tolerance for risk, and to be OK with not seeing “progress” each and every day. This opens the door to creativity and innovation.

It also entails taking a different approach to costs than waterfall . Let’s take a look into that.

Approaching Costs With Agile

When a project follows a predictive method, it’s easier to know all the costs up front.

Budgeting and managing costs means taking a “percentage complete” approach. At the beginning, the team determines all the tasks to do and the amount of money required. Gauging how the project is going means looking at the percentage of work that is completed compared to the percentage of the budget used up.

This method keeps a team bound to all the work outlined in the planning phase. With agile, however, it’s impossible to create a complete task list at the beginning, as change is implied and accepted. And so the percentage complete approach won’t work.

A more suitable method, then, is budgeting month to month. The manager determines how much the team costs for each iteration, and then looks at the duration of the project in order to determine the overall cost.

This set-up allows the team to create some code, get it in front of the customer, then possibly rip some of it apart and re-create it again with a more customer-targeted approach the second time around.

Although monthly budgeting is superior to a percentage complete approach when dealing with agile projects, this doesn’t entirely answer the question of costs.

In the next section, we’ll look at various methods and artifacts that allow agile teams to assess time and costs in order to accurately forecast a project’s cost over its timeline.

Part II: Managing Costs in Agile Projects

In order to look at managing costs with agile, let’s start with an example.

Let’s say a team has the job of designing an ecommerce store, and the client has a budget of $300K. The client certainly wants a successful store, not simply a completed project, and so the team plans to take an adaptive approach of seeking feedback from customers, then pivoting and tweaking in order to make sure all the features are user friendly.

How can the team know if it’s able to complete the project within its budget? Let’s look at some agile artifacts that help manage project costs. These first three look at budgeting from a cost approach.

1. Burn Rate

The burn rate cost approach uses a burndown chart. This chart plots how much work is completed on a project over its timeline. Time is plotted on the horizontal axis, and work is plotted on the vertical axis, starting from total work at the top and working down to completion. At the beginning of a project, an “ideal work line” is drawn to indicate the work goals at each time interval. Completed work is measured using story points. A second line, the “actual work line,” is drawn as the project progresses.

A burndown chart helps a team visualize how far along they are, and whether they’re working according to plan. It is commonly used in the scrum framework.

Calculating the burn rate means looking at the actual hours each member works during each iteration, versus the story points completed. Next, this value is compared to a calculation of the ideal work rate. The difference between these two values lets the team know if it’s staying on track, and by how much.

2. Precision Alignment

The precision alignment method for cost estimation entails looking at the final product, and outlining all the key features that must be included.

For example, with an ecommerce store, these features would include the checkout page, the listing page, a sign in page, and the cart.

The team looks at each feature and estimates how long each should take to complete. Then, it multiplies this length of time by the cost of the team per week. Adding these numbers yields the total project cost.

Precision alignment is a very simple and straightforward method. However, it doesn’t entirely account for pivoting. For example, agile allows for changes late in development. In the ecommerce example, the team may listen to feedback and decide to scrap the checkout page and start from scratch, which could add a lot to the length of the project.

3. Relative Comparison

This method for cost evaluation entails comparing a current project to a similar one from the past. In order to forecast accurately, it’s necessary for the same team to have worked together for six months or more.

To make the simple calculation, the team looks to a previous project, and multiplies the length of that project by the cost of the team per week.

For example, if a previous ecommerce store took five iterations, and the team costs $30K per sprint, then the project should be $150K.

When the team doesn’t have a similar project, it can look at its velocity from previous sprints to create estimates. The average velocity gives a gauge for the amount of work the team completes in one iteration. Dividing the total points for the next project by the average velocity gives an estimate for the total number of iterations to complete the project.

In sum, all three of these approaches work similarly. It’s possible to combine them, depending on the experience and preference of the team. Forecasting is more dependable when the team has worked together for some time. This way, it has a lot of sprint data and previous projects to compare to its current projects.

Time Management

A project’s cost is closely related to its duration. When you can make a good estimate of how long a project should take, then you can probably make a pretty good estimate of its cost. Here are some agile methods and artifacts that assist with time estimation.

1. Project Road Map

The project road map is kind of like a project’s long-term plan, but the dates aren’t bound and fixed as with a gantt chart. It seeks to answer the how, the what and the why of a product plan.

The road map frames a project around dates, and the work is broken down by themes, releases, epics or sprints. It is created with the overall goal in mind, and so it’s necessary to seek input from all stakeholders when putting it together.

Although the road map is used as a guide to gauge when certain milestones are completed, it does get updated as the project progresses, so the dates aren’t set in stone.

2. Release Plan

A release plan is similar to the project road map. It focuses on various stages of the product development, which provides a scope and timeline for each release.

A scrum team only works on one release at a time, and so the release plan allows you to estimate a project’s length by determining the length of various release stages.

3. Product Backlog

The product backlog is another method for estimating the duration of a project. The backlog includes a list of known product requirements. When each of these requirements has been assigned user stories, it’s possible to estimate how many iterations it takes to complete them all.

The team looks at its average velocity from previous iterations, and then adds up the total number of story points in the product backlog. Next, it simply divides the total number of story points by the velocity to discover how many iterations it will take to complete the project. This provides a good estimate of the project’s end date.

This method appears simple and straightforward; however breaking down all of the stories in the product backlog really is an immense task. This entails playing several rounds of planning poker to get the user stories broken down into items small enough for individual iterations. If the user stories aren’t broken down, and instead are assigned immense point values, this would probably result in an inaccurate estimate.

In sum, finding an accurate estimate for a project’s duration is key to knowing the cost of an agile project. And the good news is, oftentimes agile projects take less time than waterfall—which means money saved for the company!