Have you ever noticed how predicting the travel time of an international flight covering 4,000 miles is often more accurate than predicting the time to commute to your office? The same is true of software development projects — it can be easier to predict longer term schedules.
Here’s why. We’ll ignore catastrophic situations. Some flights arrive at their destinations a day late or are cancelled. Some commutes are so horrible that people work from home or take the day off rather than deal with them.
Normally, an international flight covering about 4,000 miles is likely to take about 8 hours. That’s roughly the distance from New York City to Berlin. The time will not be exact but is likely to be fairly close — let’s say within plus or minus 45 minutes or about 9%.
My daily commute time varies more widely depending on the road, traffic and weather conditions. Here’s a breakdown of the typical travel times I encounter from week to week:
- Ideal time: 20 minutes (light traffic, good weather)
- Typical time: 25-30 minutes (rush hour traffic, good weather)
- Poor time: 35-40 minutes (rush hour traffic, poor weather or minor road blockage)
- Horrible time: 45-50 minutes (rush hour traffic, bad weather or major road blockage)
So the difference between the ideal time and the horrible time is a factor of almost 2.5 or 150%. Does that mean that if I want to be certain of getting to the office on time, I should allot 50 minutes to get there? Yes, it does.
How can it be that a 4,000-mile trek can have a much smaller, arrival-time window (percentage-wise) than a 10-mile commute?
It’s actually quite simple. The longer trip has many opportunities to self-correct and adjust. The aircraft can speed up, change altitude, and alter flight paths to make up for a delayed departure or adverse weather conditions. My short commute by automobile has few alternatives, if any.
What does this have to do with software development?
- Longer software projects have more time to adapt and adjust — if they give themselves opportunities to do so. Rigidly planned projects leave no room for adjustment. Once they begin to deviate from the plan, they’re trapped. The only option is to stop and re-plan. Lost time leads to wasted time. A difficult situation becomes insurmountable.
- Scrum projects using short (2-4 week) sprints may miss their sprint targets occasionally — at times they’ll under-deliver and at other times they’ll over-deliver. Both outcomes are okay. The individual sprints don’t matter nearly as much as the collection of sprints that make up an entire release. Sprints are learning experiences. It’s okay for an occasional sprint to fail. It’s not okay for releases to fail.
Here’s My Advice
- Set final release deadline dates and don’t move them! Commitments matter.
- Keep release schedules at no more than 12-14 weeks. If the scope is too large to fit, break it up into two or more releases.
- Keep sprints short. I recommend 1-2 weeks for experienced teams. Less experienced teams can go up to 4 weeks.
- Group sprints into phases — Inception, Elaboration, Construction, Transition. (See this series of posts.)
- Adjust scope (feature set) as needed to make release dates.
- Maintain high levels of quality at all times. Keep technical debt under control.
- Keep stories small, as in 1-2 days of work. If they’re small enough, there’s no need for estimates.
- Use feature toggles — liberally — to manage the delivery effort. If a feature isn’t ready, toggle it out.
- Make time for architecture, design and long-term planning within each sprint.
- If you’re forced to reduce the release scope to the point where business value is too low, you’ve failed. Regroup and begin again.