I’m late! I’m late!  My whole project is late!

Can an agile project be late? What does it mean for an agile project to be late? There are really two different kinds of lateness for agile projects.  First, there’s the kind that everyone thinks of “this project will take 8 sprints instead of 6 so release it”.  Then there’s the more insidious kind, “these stories got started but not completed in the sprint”.

What does it mean to be late

Lateness is a failure to deliver on schedule, anything can be late. Like everything else in life, it is a matter of how you deal with the problem that determines how important the delay is.

If you keep to the more traditional view of agile/scrum development, where each iteration results in a release ready increment of software, an extra sprint or two to get some needed features for the release complete is no big deal.  If the release needed to happen no matter what, it can and there can be a followup release when the additional features are ready.  This is very close to the ideals of a lean development method.

However, if the cause of the delay is partially completed stories there is a larger problem. Basically, there is a half finished story that can’t be released.  If there is a single development branch instead of developing features in isolation, then the whole product can’t be released.  There is little to do to salvage the situation. There are pretty much two options: fix/finish the stories or remove them from the code base. Obviously, this second kind of delay is something that you want to avoid at all costs. Half completed work is a leading cause of failure in agile projects.

Why are you late?

This is the more important question. Analyzing the cause of the delay and fixing it is the first priority.  Actually, it should be built into the agile life cycle, but people tend to forget about it. The root cause analysis of problems is one of the functions of the retrospective meetings.

As a general rule, delays fall into some combination of three categories: missed requirements, missed estimates, or external factors.

Missed Requirements

Missed requirements is another tricky area.  Strict agile doctrine suggest that when you realize that you have missed requirements, either document them as a new story for the new requirements or pull the story from the current sprint. Both of these approaches lead to the same basic problem: work being partially completed and not in a functional state.

However, knowing that there were missing requirements gives you an easily identifiable goal for the next time the backlog is reviewed.  Namely, thinking about what was missed and how to add it.

Missed Estimates

Poor estimates are the bane of agile projects. It is fairly safe to say that any estimate is wrong.  The question really boils down to “by how much”. When you decide the capacity for a sprint, whether it’s using the “yesterday’s weather” method or some other heuristic, you are basing that capacity on the estimates for the stories. When those estimates are off, and some of them will be, how do you figure that and and what do you do about it?

Theoretically, the “yesterday’s weather” approach will mitigate this somewhat. If the number of stories/story points that gets completed changes dramatically, then velocity and capacity change accordingly. Although this is based on the premise that we are consistent in sizing the stories.

Every once in a while, there will be a story that just got misunderstood and the wrong estimate got applied, it should have been a 12, but got sized as a 2 or vice versa. So how do you identify those items so that they get sized correctly in the future.

The short answer is experience, but that’s not terribly helpful. Basically, part of the retrospective needs to be looking back at the stories that were completed to see how well the level of effort and estimated corresponded.

If they don’t correspond, the easiest way to start the discussion is with the “5 why’s”. Hopefully, getting down to the root cause will help flag what could be missing in future sizing estimates. Most of the time, it will come down to some missing requirement. Either a systems integration requirement, or some implied but not stated business reason.

External Factors

The external factors are the easiest to understand and the hardest to account for. An external factor could be everyone getting the flu and being out for a couple of days. It’s kind of hard to plan for that and mitigate the problem.

Conclusion

Agile development is at it’s heart a feedback loop where learning about what happened informs how you’ll proceed.  Take advantage of the learning opportunity when the project is late to set yourself up for success the next sprint or the next project. If you don’t, you’re not really doing agile, just some kind of cargo cult development.