Agile software development is about delivering customer value. Since all work is geared toward customer value and a working product from the get-go, it is by nature more efficient and less wasteful. A well-run agile development is agile because it is adaptive and responsive to changes. If funds are depleted or requirements undergo major changes, the customer will still end up with a working product. Agile development makes so much sense that it has been widely adopted beyond software development.

Agile software development is about delivering customer value.

Great, but does it mean the cost isn’t going to exceed the estimate like software projects are known to? How do you manage and estimate cost?

One common snarky answer is: Agile software projects need a budget, not an estimate. Substituting budget for estimate would make things so much cleaner and life so much easier. Unfortunately, things have a way of getting more complicated than they look, and we’re about to get into it.

Do Agile Projects Need An Estimate?

The answer to this question is another question: Why does the client think an estimate is in order?

If the answer is merely to hold the developer to a firm commitment or to turn the proverbial screw on the developer if they didn’t live up to expectations, then we’d be inclined to say no. On the other hand, if major decisions or plans are riding on the estimate, we’ll have to dive into it.

You’ll find that sometimes a project is so urgent that, as long as the client and provider can come to terms, it has to be worked on right away without an estimate. A project in the exploratory phase requires just a rough estimate for the client to allocate the appropriate funds or decide if they could afford it or wait for it to complete.

The whole point of agile development is not to be married to the original expectations, which may not even be feasible, so most estimates are by nature on the rough side. In any event, there are always times when we will have to develop a more detailed estimate.

The 5 Steps of Estimation and Planning

Estimation and planning are deeply intertwined in agile development. Tools are available for tracking the efficiency of the process. Another characteristic of agile development is that the estimate can be updated as often as needed, so it is not a problem even if the details of a project are unknown in the beginning.

We will be using the Scrum framework of agile software development. There are 3 roles in a Scrum project: Product Owner, ScrumMaster, and Team. A backlog is a list of features and a backlog item is a feature. A backlog item is recorded in story format called user story, which can be further broken down into story points, the sum of which represents the amount of effort needed complete the user story of feature. A sprint is an iteration. The rest will be introduced as we go along. (The Scrum nomenclature is useful beyond its elegance. Why not a sprint instead of iteration that puts people to sleep? Would you rather be assigned story or work?)

1. Create Backlog

A product backlog is a list of all features in the product. First, we break up the initial idea into smaller features or backlog items. The initial idea may be abstract but backlog items must be definable. These backlog items are recorded and told in user stories. An agile user story describes the feature in any level of detail that can be continuously modified. The product backlog is planned in advance though naturally it will evolve as each user story is modified, added, or dropped. A backlog can contain dozens or even hundreds of user stories.

2. Prioritize Backlog Items

Arrange user stories in the backlog in order of decreasing priority (to be performed by the Product Owner). In keeping with the principle of delivering value early, Agile software development always starts with the high priority items.

For example, to build a Magento eCommerce site, inventory management and shopping cart would be higher priority than reviews and blogs. The site would still be functional even if the project did not proceed to reviews and blogs.

3. Estimate the Project Scope

Estimate the scope of the project by adding up the total number of story points. A Scrum Team of developers assigns the number of story points to every user story and the grand total of story points is a rating of the scope and complexity of the project (higher is more complex).

Each user story is assigned a Fibonacci number, say from 1 to 21. The number in ascending sequence reflects the complexity of a user story, and thus the relative amount of effort required to complete. This number would become the story points of said user story. Note that a story point of 8 doesn’t mean the story would require 8 hours or anything like that in a sprint – it’s just a preliminary number of story points, and a popular practice for determining this preliminary estimate is Scrum poker.

Scrum poker is believed to reduce cognitive biases of anchoring (over-reliance on the first piece of information) and the Dunning-Kruger Effect (an illusion of grandeur).

4. Estimate the Project Time Requirement

This estimate is not a precise date of completion. Start with a product roadmap and release plan. The product roadmap of an agile development shows the product’s evolution through a number of major releases. The release plan is an advance schedule of major releases based on the product backlog.

The project time requirement is estimated for each sprint. The metric is velocity, which in Scrum is the number of user stories completed in each sprint. A good guideline for predicting initial velocity can be found in Mike Cohn’s blog post. The estimation of time requirement is an iterative process as the velocity fluctuates before stabilizing after a few sprints.

The incremental nature of agile development means the product can be delivered piecemeal, each of them a working and shippable product if not complete. How much and what functionalities to release can be managed and controlled in ways other than deadlines.

5. Estimate the Project Cost

Calculating the project cost estimate is rather straightforward once the project scope and velocity are known. There are two standard approaches toward that: via blended rate or specific labor categories. Check out the write-up by Jesse Fewell as the details are beyond the scope here. Both methods assume constant Team members and sprints as figured in the release plan.

A quicker estimate can be obtained by calculating the team burn rate per sprint and assuming that it’s fixed. The total number of sprints required can be calculated by dividing the total user stories by the velocity.

Most service companies have a rate sheet of hourly rates for each labor category. Each team member’s (including Product Owner and ScrumMaster) burn rate per sprint is: Hourly Rate x Working Hours/Day x # of Days in a Sprint

And the team’s burn rate per sprint is the sum of each member’s burn rate per sprint as calculated above.

Though assumed fixed, the estimated team burn rate per sprint can also be continuously refined as the actual velocity is known after the completion of each sprint.

Tracking of Workflow Efficiency

Agile software development is inherently more efficient. In addition, there are workflow efficiency solutions ready-built in Scrum and other agile frameworks. At the end of the day, however, it takes insights and able management to be absolutely sure that resources are not going to waste at any point during the development.

The presence of positive synergy and the concurrent absence of adverse conditions are key to efficient workflow. To achieve positive synergy is to create an environment in which individual efforts are directed for maximum impact. Adverse conditions in software development include but are not limited to encountering bottlenecks and piling up code debt.

Many activities in agile development can be automated with the ultimate goal of workflow efficiency. One well-known and proven tool is JIRA Software, a customizable agile project management tool with support of all agile frameworks including Scrum and Kanban and their popular variations.

Burndown Chart

A burndown chart tracks the remaining tasks to be completed in a sprint. It’s a chart with planned amount of work (user stories, story points, or their equivalent in days) on the y-axis and sprint timeline on the x-axis. The plot would start from the planned total number of user stories in a sprint and “burndown” to zero, hopefully at or before the last day of the sprint cycle.

Two lines or curves are plotted on the chart. One is the projected or ideal burndown rate and the other the actual burndown rate plotted at the end of each day.

The burndown chart of a sprint keeps track of progress and indicates whether or not the team is on schedule to complete all planned work at the end of the sprint. Team members would know when to compensate as needed by keeping an eye on the sprint burndown chart.

The burndown chart can be extended to the whole project by extending the x-axis to the projected release date and y-axis to the planned total number of user stories or story points for the project. This is known as the release burndown chart, as opposed to the sprint burndown chart.

Earned Value Management (EVM)

Earned Value Management (EVM) has grown to become a wildly popular method for measuring agile project performance since it was introduced to agile frameworks in 2006. EVM is most commonly applied at the release level rather than individual sprints.

The various metrics of EVM are calculated from the planned number of user stories and the number actually completed. More specifically, we are going to look at just 3 of them: actual cost (AC), earned value (EV) and planned value (PV). AC is the actual cost of work performed, EV is the budgeted cost of work performed, and PV is the budgeted cost of work scheduled.

AC, EV and PV can be incorporated into the release burndown chart to illustrate the efficiency of an agile project at any given stage. The project’s total cost and duration as forecasted by a release burndown chart with EVM afford the client and provider valuable time for making informed decisions about changes needed or desired.

EV is an important measure of cost efficiency but more often than not it does not equal to AC and PV. This is either caused by efficiency-related issues such as workflow inefficiency and misalignment of priorities and estimates, or other variables such as initial ramp-up and changes in requirements and priorities.

EVM data is historic, current and predictive in nature. It allows the use of historic data for iterative estimates, diagnosis of current data in tracking, and prediction of future data for timely decisions to optimize customer value.

The EVM data indicates the presence or absence of inefficiency and not much more. It is up to the Team to find the cause of the inefficiency. Would a StrumMaster stake his or her reputation on identifying the real cause?

True Values of Agile Development

Agile software development delivers customer value early and often. After just a few sprints, an agile software product would be ready for premature release with all core features in place and its end users might not know any better.

Agile development thrives on changes so detailed planning can be left in the rearview mirror. It is best to dive into development with just a preliminary order of priorities. Track the progress every step of the way in order to be able to devise changes and make informed decisions.