I’m going to start a new practice. Before I even do an estimate for a client, I’m going to ask:

Which is more important to you: having it done by a certain date, or having all your features 100% complete?

Two extremes: I’m dealing with a client right now that has a very firm, but internal, sense of when they want my current project done at. I’ve dealt with clients in the past who don’t care when it’s done, just as long as its perfect when we ship.

These are both legitimate decisions.

In the former case, if your ship date is set, then your development team needs to know it. It can even be in the form of sprints: “how many sprints do we have until ship date: 3, or 6?“. This is important, because it gives me a sense of urgency: how hard do I have to push back when scope increases, how conscious do I have to be about my time?. How closely does the dev team’s PM have to monitor developer’s feelings of progress?

It’s the old Parkinson’s Law in affect: if you tell me 6 sprints I’ll take 6 sprints: I might spend a few hours refactoring something here, or shaving a yack. Stuff that needs to be done, of course, but if you tell me 3 sprints I’ll work that much harder to ignore hairy yacks (“Ok, whatever, it’s taking too much time: I don’t need to fix it now, just get it up and leave a TODO item for later”).

A time limit also forces an agile team to think about pushing back. As scope increases on you, or additional bugs get entered by QA, this deadline determines your behavior. In short: how hard do you (or the direct management of your development team) have to watch your engineering time?

Now, a scope increase could be implicit as well as explicit. Implicit scope increases take the form of: “When we went to implement this, our initial estimates said it would be easy, but it’s now consumed 3 engineer/days… not so easy after all, actually”. Explicit increases take the form of new requirements, and (to an extent) bug reports.

With a firm date you can sit down with your client and have a discussion about these things, approach it in an agile way. Do they still want that “small thing that grew to 3 engineer/days”? Or would they rather get started on implementing different functionality?

Both of these answers are right, in different contexts. That’s why the conversation is there. With a deadline, especially a tight one, you need to make sure you are evaluating from sprint to sprint and making decisions agilely, based on the changing gestalt of the landscape.

I thought there’s a quote, but I can’t seem to find it now, from some military general, about how a plan only lasts a few minutes in actual battle. Same here, in the software development world.

Yes, these are just two sides of the Project Triangle. I’m assuming, for this article, that your team size/cost is set. But maybe it’s not (bully for you!)