When most 'Agilistas' think about agile, we think about a scrum team. We think about the events and artifacts contained within a sprint and how the team is working to complete all those stories within the sprint timebox. But unless your IT department has converted to agile en masse, your first agile teams exist within a broader organizational structure that is geared towards a waterfall model. So how do you handle all those ancillary systems outside your agile team while at the same time trying to make sure the team is able to do their work? In general, my philosophy is to minimize the disruption to an agile team caused by these systems.
In this set of posts we'll look at various processes you will likely need to work with as you bring your first agile teams online and how to 'fit in' to a waterfall environment’s existing processes while protecting the agile team from these external forces. These processes include:
If there are other processes you’d like to see addressed in these posts, please leave suggestions in the comments.
Budgeting for Agile Teams
For most companies budgeting for a project begins with a project business case. A high level description of a large project is established, and the IT department spends time coming up with an equally high level estimate of the spend needed to complete the project. Many projects are then compared, and those projects with the highest return are approved and a budget is established. In an agile world, however, teams are not project focused, but product focused. So how do you fund a team around a product instead of a project? Two options for handling this are:
- Ongoing Funding
Many companies establish an ongoing support / maintenance budget for existing systems. If you are able to justify the budget for your agile team this way that is the simpler way to do it. Budgets are typically calendar based, so you would need to re-establish the team's budget every year, quarter, or whatever cycle your budget system is on. Fortunately, one of the characteristics of a good agile team is that the team is fixed. You can typically budget 100% of each person on the team, and the team members don’t change. So if you have 8 people on your team at an average rate of $50/hr and you run 2 week sprints, you can plan on $50/hr x 8 hrs/day x 8 people x 10 days/sprint = $32,000/sprint. Simply multiply this rate by the number of sprints you are budgeting for and you have your budget.
- Product Roadmap Funding
The Product Owner should have a Product Roadmap for the product. This is a high-level idea of how they expect to see the system evolve over the next few years. In this scenario the Product Owner submits a project business case for 1 or more of these concepts that the team has determined will roughly fit into the timeframe for the budget. So if you are doing an annual budget cycle, what the team thinks they can realistically get done in a year. One way to approach this is to size projects in 'feature points'. Similar to how you would normally break an Epic into stories and size the stories in story points, the team would look at the projects on the Product Owner's roadmap and break them down into features. Over time the team will be able to estimate their 'feature velocity' over longer periods of time (e.g., feature points per quarter). While feature points and story points will be correlated, you need to resist the urge to come up with a formula for converting one to the other. Feature points, like story points, are a tool to help the team estimate what work they can get done in a certain time frame. Once you’ve determined that a set of features (loosely equivalent to a project in waterfall terms) should take a certain number of sprints you can apply your cost per sprint (calculated above) to get an estimate for the total cost of those features.
Note that this is simply an estimate of effort and cost, not of the schedule. Since we don’t know in advance what will be included in future sprints we shouldn’t assume that a set of features that takes five 2-week sprints will be done in 10 weeks. That depends on what else is in the Product Backlog and the relative priority of those features.
Another component of the budget for an agile team is work identified for the team coming from projects for other (waterfall) teams. For example, if we know an agile team will have work to do in support of a waterfall project, they'll want to get a feature point sizing on that work as well, and to include that in their backlog. This will help to make sure the agile team is sized to handle all the work in their backlog.
Tracking Planned vs. Actual
If you are lucky enough to be following an ongoing funding model for your agile team, planned vs. actual is trivial. Since the team is 100% dedicated and fixed in size, and sprints are fixed in length, your actual costs should always equal your planned costs.
If your budget is based on a specific set of features you may need to report progress on those features compared to the budget allocated. If your team is working on many things at once (features, bug fixes, work needed to support other projects) how do you track your actual spend against what was planned for a set of features? As part of your backlog refinement you will be taking these large features and breaking them down into stories, and then estimating those stories in story points. You can then use those story points and track how much of a feature is completed in a sprint.
For example, let’s say you are working on a feature that was budgeted for $100,000. You broke that feature down into 10 stories for a total of 50 story points. During your latest sprint you completed 3 stories worth 10 story points. For that sprint you would say that you completed 20% of that feature (10 story points completed / 50 story points in total). You would then take 20% of the total feature budget of $100,000 and get $20,000 worth of value delivered during that sprint. If there were stories for other features being worked on in the same sprint you would calculate the value delivered for them as well and add those together. You can then compare the actual value delivered to the planned spend, which is just the cost for 1 sprint (in our example above, the $32,000).
Doing agile in a waterfall environment not only can be done, but in the early stages of adoptions probably must be done. The key is to look for the simplest way to fit in while remaining true to the spirit of agile. As you migrate more teams you can inspect and adapt the systems to be more agile-friendly, but don't try to eat the whole elephant at one sitting.