LitheSpeed received a question from a student about an issue their company was facing during project planning. We believe this issue is a common one and therefore decided to share the conversation.
The company in question was experiencing growing pains, especially when it came to planning and forecasting. In their experience, the high level planning done months before a project began did not match the lower level, detailed planning done right before the start of each project. Large changes in cost and scope right before project starts made it hard to manage business expectations and set predictable delivery dates.
Arlen Bankston, LitheSpeed’s managing partner, had this advice:
Agile planning largely relies upon a rearview mirror approach, and in longer-term budgeting activities, this is going to be the most reliable method. Velocity is a simple local example of this; by paying attention to the output they’ve actually achieved recently, teams get a good average idea of their capacity over time. You quite often see consistent overcommitment by teams who ignore their previous velocities (or fiddle with the estimates too much) when forecasting future sprints. This empirical approach can also work at higher levels for business planning.
A local client of ours named Opower tried an interesting technique; they let business managers “buy” time from their teams by using tokens, where a single token represented the output of any given team over a single two-week sprint (the teams were similar enough that this was effective). They distributed the tokens over various stakeholder groups that requested development time, and were able to see that while they had roughly 100 tokens available the first year (five teams, ~20 sprints), the business demand for high priority efforts ended up closer to 200. So they hired more people, thus matching observed demand to real capacity. The key is that they maintained the discipline to keep teams stable and dedicated over time, rather than multiplexing them and moving people around. Many companies have very little idea of their true capacity, because constant adjustment of resource allocations makes it extremely fuzzy. They tell some of this story in an article they wrote for HBR.
Another core idea is that both planning and estimation work much better when you actually understand the work, which usually requires some reasonably in-depth analysis done by whomever is actually going to execute. You’ve already seen this, as your localized three-day sessions produce much better forecasts than the far-removed business side’s. However, as waiting until you’re starting the work to get a sense of its likely cost is unpalatable for the business, you can combine this with some projections based on something like the past few months’ output from the teams in question to get a decent mid- to long-term forecast for budgeting purposes. Put simply, whatever you spent last quarter will often be quite similar to what you’ll spend this one, as long as you’re not substantially changing team composition or making capital expenditures.
So, a few direct tips to sum this up:
- Keep teams as stable as possible. This makes everything more accurate and consistent, notably velocity, and will more importantly tend to improve productivity and collaboration. Bring work to established teams, rather than establishing teams around projects.
- Match estimation granularity to the timeframe:
- For project portfolio management and ROI projections, use something very high level like S/M/L/XL, based on projects of similar budgets in the past.
- For release planning in the 1-3 month timeframe, use something like story points or story count, but decompose anything larger than ~2 weeks of effort (roughly 8 points, if 1 point is similar to a day), as large things tend to be larger than you expect once you break them down.
- For sprint planning, keep things to just a few days of effort, likely 1 or 2 points (or just use story count and a range, such as 6-8 stories/sprint).
- Favor ongoing engagement over long-term projections. Encourage your business stakeholders to stay in the loop and ensure them that you won’t allow any nasty surprises to sneak up on them and will provide frequent updates and more accurate forecasts over time. Don’t make promises many months out, because you won’t be able to keep them.
- Consider incremental funding strategies. The expectation that business planning for software projects actually works over a whole year is a thoroughly debunked artifact of waterfall project management, as evidenced by all the time organizations spend re-planning following annual budgeting efforts. The wiser approach is to keep a sense of how much you need to spend total, then allocate as time proceeds based on current needs, which gives the business more flexibility in managing both their budgets and the development efforts they’re funding.
You can see some current lines of thinking on this and budgeting in general here: https://bbrt.org/.
