If you’ve read any basic agile stuff, you know that agile teams deliver value in a consistent frequency. The team works on what’s important first, giving the best value for money. When working in a consistent velocity, you can estimate very accurately when features are going to be delivered.

Prepare yourself for a shock.

It is true that when the team has gelled, had enough experience in estimation, and is moving in a constant velocity, life is good. But most people are not there. Chances are, that you’re struggling with inconsistent estimations, varying velocity, some turn over for good measure and enough unknowns to fill  multiple buffers in a Gantt chart.

There’s an old myth: There’s no planning in agile. You’ll find there’s a lot of planning, but if done “right” it’s mostly short term. There’s logic behind it: The bigger the task, a lot can change on the way. It makes much more sense to cut it down to smaller bites, estimate and deliver them, and move on to the next important feature.

However, most of the real world doesn’t work like that. In my former job, I managed software projects of medical instruments that needed to be ready for an expo, after FDA submission. The expo was on a deadline and the competition didn’t wait. The project sponsors needed to know everything would be ready in time, three years in advance.

You might be surprised to learn that answers like: “It will be ready when it’s ready” or “you’ll get what’s the best value every month” were not pleasing to the project sponsors’ ears. See, they needed to know what they’re getting and that it will be on time. Couldn’t face reality, the old geezers – they wanted actual long term plans.

Well, these are the guys who put the money into the project. They may have unreasonable demands, like wanting to know exactly where the project is, but the expo is not moving, is it?

Pure agile may work, but business people are so tired from earlier failures, they don’t trust the team anymore. And they are looking for reassurance or control, by demanding more information. And I’m sorry to say, they are right.

They need answers, so they can make better decisions.

So what can you do when presented with the unreasonable question: “When will it be done?”

You plan, even for the next 6 months, and stand behind your plan. This would be a rough plan, but will present you’re working on the correct features. When progressing, update the plan, and communicate your status. And apart from that, you present working software, showing continuous improvement in the product.

Sounds like the old waterfall world calling you back?

Well, that’s the real world. It requires balance between the long term and the short term. Agile planning is not enough.