On an agile software project, we readjust plans daily. We pivot to respond to change, discovery, and feedback. Product owners and stakeholders, on the other hand, focus on longer-term planning — defining product roadmaps, release dates, and milestones.
As a Delivery Lead, I have the challenge of balancing planning needs for the entire team. Fortunately, despite what you’ve heard, it is possible to plan more than a few weeks out on an agile project. Agile doesn’t advocate for the absence of long-term planning, it just provides the flexibility to prioritize and rework the plan regularly to meet your project goals.
Surrounded by Uncertainty
In a perfect world, projecting project “completion” would be a matter of simple math. I’d tally up total points remaining in the backlog, divide by average team velocity, and voilà! I’d know exactly how many iterations we’d need to get everything done.
But the real world is never that simple:
- It’s difficult to assign accurate estimates to agile stories early on. We may not understand a story’s complexity in full until we dive in. And we’ll probably run into emerging requirements and volatility in team velocity.
- Often, project requirements are still in flux when the development team ramps in. We may only have enough actionable work in the backlog for another sprint or two.
- Team members leave and join the project. People take sick days and go on vacation. Life happens.
How can we even begin to determine when everything will be “done”?
Estimate Your Undefined Backlog by Working Backward
The best way to combat uncertainty is to constantly work on the backlog — prioritize and refine daily based on project goals. Of course, the time to do this is often a luxury. Your client may be under pressure to provide a release date. You may need advance notice to secure continued funding. In this case, the best way forward is by planning backward.
Initial Estimation
Start with your target release date, then break each project goal down into chunks. You won’t yet know how long each piece will take to complete, but your stakeholders can help you determine the relative size and effort of each. Areas providing high business value should take up the lion’s share of the effort. Then divide the remaining time among the remaining chunks. This will establish a rough “effort budget” for each.
Note that these estimates should encompass the time the team needs for a “job well done.” Don’t estimate the time needed for a bare-bones implementation, and don’t plan for a wildest-dreams scenario. Finding that middle ground will enable you to whittle down as needed and respond to change later. If you’re new to range estimates, you can learn how to get started here.
Sprint Course Corrections
Cue the passage of time and the inevitable reduction of uncertainty! After a while, we’ll be able to accurately estimate what we can complete in a single iteration. Now we can see if our original estimates meet or exceed the budgeted effort.
It’s time to engage stakeholders in the decision-making process. If this chunk will take a month longer to complete than expected, where can we pull that time from? Are there any nice-to-haves in the scope for area A we could cut to leave breathing room for area B?
Before you know it, your short-term planning is working in concert with your long-term plan. With defined targets in place, a short iteration cycle allows for constant prioritization. The development team can align on which tasks to tackle first. Focusing on stories that provide the biggest impact also reduces the risk of wasted effort.
This approach may not be perfect; planning never is. But in the midst of uncertainty, I try to remind myself: “A good plan today is better than a perfect plan tomorrow.”