Everyone likes to know the answer. In fact, this question can be interpreted in many ways, and answered that way too. For example, if we’re using agile techniques, we assume things will go wrong. So what we’re asking really is when is the scope going to be completed.

And that’s not the way agile works, does it?

What we do is set deadlines.  Some of the deadlines are real – like a tradeshow we need the product for. Some are there because someone just put a date on the table. Once we have a deadline, we’re starting our way towards the goal. Iteration by iteration, changing scope by feedback, making the best product we can for our customer.

If we get to the deadline, and there’s no product yet, we’ll push the deadline. Or miss the tradeshow. Regardless, we make a conscious decision about if we’re ready to release or not.

So if we know the dates are set, why does the question “when will it be done” still pop?

If the project is already on the way, what we’re really asking is “Is the scope going to be ready on time”.

Which goes against what we’re trying to achieve: Best value for the customer does not come from a predetermined backlog of features. It comes from the iterative nature of development. When we’re talking to managers who are new to agile development, this is usually what they mean

There’s a bit more to that: Dates are easy to explain. Scope is harder. “We’ll have X baked in, but only some of Y, and a bit of Z”. Managers are there to make decisions. It’s easier to make a decision about a date. With scope you  need to drill down. Good managers drill down to understand the details, so they can make informed decisions. Some aren’t able to make decisions, but we’re not talking about them today.

In that case, we need to explain what we can have by what date. Help them make the decision, and by the way, educate them about the agile process. It may not be our job, but if we want to continue doing agile development, we’ll need management backing. And we’re called to the flag.

Agile-aware people will ask another question, or mean the question in another way:”What can we get in to product by the deadline”. This is an already informed question about how we do things, and there’s an expectations for the answer to be about features. As with any communication, our answer should depend on the knowledge level of the person we’re talking with to explain, but the discussion will be more focused than the former.

Yet sometimes the question is asked before the project even started. It really means:”Is the project feasible?”. Or more delicately, is it possible to do this by a certain date. If the project hasn’t started yet, we probably don’t know much about it. We can either compare it to what we did before, or guess. The guess should not be a yes/no guess. The problem is that the answer “probably” will be translated to an an affirmative yes. What managers want to know is that you’ve actually though about it, so we expect a date range, a plan and assumptions. If it’s not enough, the manager will ask more questions. Let’s remember: management invests a lot of money in a project. Managers want to know they are not throwing it away. They want to trust you, and plans and assumptions raise that trust.

Dates dictates how we manager our projects. Milestones, arbitrary or meaningful, are the driver behind projects. Within the the project time, we should work on what’s best for the customer, realize what we can put in the product and communicate the details.

Communication leads to trust. Without trust, we cannot achieve sustainable agile process.

So let’s work on that, shall we?