Agile software development, if properly managed, is all about becoming more productive, reducing unnecessary work (waste) and switching the focus from deadly deadlines towards generating customer value.
‘Perfect,’ you say, ‘but how do you control finite resources, such as time and costs?’ After all, as Bill Hewlett said, ‘You cannot manage what you cannot measure… and what gets measured gets done’.
Here’s how we do it.
Our approach to estimating
Do Agile projects need estimating? The answers range from #noEstimates through ‘necessity-driven estimation’ to ‘obligatory estimation’. However, the reality persists: nearly every software development project starts with one question: ‘how much effort is this going to take in terms of time and money?’ And a common concern of Agile newbies is ‘how do I calculate the cost of my Agile project, if I don’t do all up-front planning?’ Here’s what we do.
Start with ‘Why’s’
Why do you need an estimate? Our decision will depend on whether estimates will be taken as commitments, to blame developers for not living up to promises. Then ‘No’ is on order. If a significant decision is to be made based on estimates, then we’ll go ahead and calculate. ‘Why’s’ provide a larger context to determine the necessity (as well as the precision) of an estimate.
Turn ‘Why’s’ into ‘How’s’
Now that we know exactly why the client needs estimates, we can decide on a scale. Let’s say, the client needs to know what budget to allocate, or whether they can afford the project at all. Then it’s enough to give a rough estimate by a mere analogy and leave out details. That will spare you time and effort on a project that is still quite in the air.
If there is a strategic decision to make whether to opt for plan A or B depending on estimates, we will probably have to dig deeper.
Then again, the urgency of the project may require prompt actions with no preliminary estimation, as long as both the client and the provider agree to terms.
Of course, Agile development does not claim to guarantee perfect on-time and on-budget delivery of original expectations (which may not even be realistic or suitable to meet user needs). However, in many cases, choosing the right strategy brings you nearer to ultimate success.
Estimating and planning: step-by-step guide
The primary challenge is to do estimating and planning while we still know very little about the product. The good news is we can update our estimates as often as we need. In agile projects estimation goes hand-in-hand with planning. While efficiency control is exercised through tracking. There are a number of planning, estimating, and tracking artifacts and tools.
Create Product backlog
How do we know what to build? By dividing the initial abstract idea into smaller, more concrete concepts, whose value will later be tested. Our assumptions of what a user may want are put into a simple language of user stories – specifically syntaxed descriptions of functionality. User stories are necessary to attune everyone to the same wavelength. They make up a Product backlog, a list of the total functionality for the product. We plan the backlog well in advance, but of course, it will evolve over the time, reflecting all the changes in scope and direction of the project.
Prioritize Product backlog
For starters, MoSCoW analysis is great for getting priorities right. It means labelling backlog stories as ‘Must-haves’, ‘Should-haves’, ‘Could-haves’, and ‘Won’t-haves’. When planning sprints, high-priority stories, or ‘must-haves’, are chosen first, according to the Agile principle of delivering value early. Priorities are set by the product owner based on business needs. Sometimes we develop an MVP first as a way of testing value of the features against end-users’ expectations.
Read also: Prioritization Techniques That Help Build Great Software Products
Size the project
The size is usually measured in story points – these are relative units of measure. They give an idea of size torn from any concrete performance. The reason for that is not to set false expectations about deadlines, because estimates are just guesses, and not commitments.
A common practice for initial estimation is by Planning Poker, aka Scrum poker. A team of developers assigns each user story some value out of the Fibonacci sequence, generally, within 1 to 8 range. The value reflects the size (or complexity) of a story (1 – for small, 8 – for huge), or in other words, the amount of effort required to fulfil the respective tasks. These are story points. Now we have a rough idea of how much effort we have to put in. But we still can’t tell how long it will take.
Time the project
Is it possible to estimate the time if we are not sure yet about changes in scope and a direction of the project or how fast we will be moving (velocity)? The answer is – it’s tough. But again, no one asks for an exact date of the project’s termination… Or do they? In that case, here’s what we do.
Get the right artefacts ready
All you need to do in advance is plan a long-term strategy (Product roadmap), specify shorter-term objectives (Release plan) and pick the right tracking tool.
Product roadmap shows how a product is likely to evolve across several major releases. Its value is explained by Gene Siciliano: ‘Fewer wrong turns means less time spent, less money spent, and more results with the same resources’.
Release plan, as compared to Product roadmap, focuses on the tactics to ensure timely release. It taps into Product backlog for details. Burndown charts are great at tracking the progress in relation to expenditure. Let the tools do the tracking job for you.
Plan per iteration – update your metrics
There is no need to plan for the whole project. Planning and timing are iterative as well, and this helps to control the estimates’ shelf-life. It becomes easier to calculate velocity as the project unfolds and gives you an idea of your best-case (O), worst-case (P), and long-term velocities (L). Then the formula
V = (O + 4L + P)/6,in which V stands for ‘projected velocity’, gives us the clue as to how fast we can be moving. But probably your pace will have stabilized by then. In case you need to make an educated guess about a team’s velocity right at the start, with no historic data, or for an unstable team size, Mike Cohn’s article gives some more insights. Just keep your metrics in sync and make timely decisions about the project’s course.
Divide and… manage
Luckily, incremental character of Agile development allows to deliver a shippable product when necessary. You can deliver piecemeal. That’s why controlling time by no means forces people to squeeze into tight deadlines. By proper expectations management, you can control how much and what exactly you want to release.
Cost the project
Now that we can tell the approximate size of the project and the team’s velocity, calculating costs is easier than you can imagine. Provided that our team roster remains unchanged and the iterations are time-boxed, there are two approaches to costing the project:
- Using a blended rate
- Using specific labor categories
Here’s how we go about calculating the costs. By knowing specific rates for every labour category, such as Product owner, Developer, QA, Designer, etc. and their workload ratio, we can calculate the team’s fixed iteration burn rate like this:
Velocity indicates how many more sprints we need to plan so that we can cover the remaining user stories.
Workflow efficiency control
How to ensure that resources are not squandered during the development? Some of the solutions are integrated in the methodology while others require skillful management and a good deal of foresight. Overall, workflow efficiency results from two types of activities aimed at:
- promoting positive synergy (conditions in which individual efforts, properly channelled, yield exponentially more powerful return);
- minimizing adverse effects (monitoring and dealing with bottlenecks, technical debt build-up).
Automating some of these activities takes a great deal of workload off all the participants. A variety of tools may help automate Agile processes. We, for one, use JIRA Agile.
How to track cost and time in Agile development
Every manager wants to know the answers to two important questions:
- Are all the planned user stories going to be completed at the end of the current sprint?
- Is the project (or release) going to be delivered on time and within budget?
A Burndown chart can give us a comprehensive answer to the first question. The second one is far more difficult and has a number of answers. Let’s look at the two possible ways to address it.
Release burndown chart
One of the options is a Burndown chart for the whole project – Release burndown chart. As soon as a team has achieved a relatively stable velocity after a couple of sprints, it becomes possible to measure the time and cost of the project more accurately and track the progress of the entire project in a Burndown chart.
Release burndown chart (Courtesy of Pablo Straub)
When the two lines showing the actual progress and the planned one are clearly visualised, troubleshooting and adjustment are not so painful and the team does not get blamed for overly optimistic original estimates.
Release burndown chart with Agile EVM
Alternatively, you may want to enhance your Release burndown chart with Agile EVM. Earned Value Management technique, widely used and approved by PMI since 1960, was introduced via Agile framework by Tamara Sulaiman et al. in 2006. Agile EVM allows to elicit even more information. Apart from tracking the actual work burndown against planned (the way a Burndown chart does), it helps diagnose a project’s efficiency at any given moment by comparing costs spent (AC – actual costs) against the value earned (EV) and planned (PV) – these variables don’t necessarily coincide. Besides, it gives us a forecast of a project’s overall cost and duration, which allows businesses to make informed timely decisions about changes in a release.
Release burndown chart for Agile EVM with scope increase (Courtesy of Chris Fortuin)
EV – is a crucial metric to track cost efficiency. However, it can often be at variance with CA and PV. Why? For several reasons.
- Efficiency-related issues
- Wrong estimates
- Prioritization-related oversights
- Team efficiency issues
- Management negligence
- Objective causes
- Initial ramp-up
- Change of requirements
- Shift in priorities
Understanding a real cause is key. If this information gets proper interpretation, it will ‘empower’ rather than ‘arm’ both parties with knowledge.
Benefits of Agile EVM
It gives us three types of data – historic, to-date, and predictive – which can be used as follows:
- To diagnose the current status for troubleshooting
- To make informed timely decisions about the release to increase business value
- To use historic data for new estimates
To conclude
Every project has a budget and, want it or not, a deadline. And every client wants the best value for money. Wise managers know better than tell employees about deadlines. Tom Demarco says, you just let your team leads know this, ‘I have a finish date in mind, and I’m not even going to share it with you. When I come in one day and tell you the project will end in one week, you have to be ready to package up and deliver what you’ve got as the final product’.
How to control finite resources in forever changing circumstances of Agile environment? Without dreading a pending deadline? By delivering maximum business value?
Here’s our answer: plan just as much as to prioritize and go into development – track the progress regularly – readjust your plan often – make informed decisions.