No Deadlines

deadline, from New Oxford American Dictionary

  1. the latest time or date by which something should be completed : the deadline for submissions is February 5th.

  2. historical a line drawn around a prison beyond which prisoners were liable to be shot.

Deadlines in software development induce unnecessary stress, and transform otherwise enjoyable activities into chores.

We need to replace deadlines with livelines. A liveline is a deployed, working version of a product. It is after the fact, a milestone set when you are done.

How Deadlines Are Set

Deadlines are set in different ways in different projects.

In the classic Death March project, a deadline is set by someone outside the project with no clue whatsoever about how long it will take. Typically this kind of deadline is based on some external event, where the project will be demonstrated. The event may be a conference, or something similar.

In Scrum, the deadlines are set by the process itself. Most Scrum projects I have worked with use a two week deadline instead of the recommended 30 days. The team decides how many stories they can complete by that deadline, based on rough estimations done in the sprint planning.

Some projects set deadlines by a developer being asked (or asking himself) when the task will be done. The developer will say: “I’ll have it done by 3 o’clock”, a wild guess.

The problem with all these approaches is that the deadlines are, at best, based on guesses of the team doing the development. But guesses are guesses, not something you can set a deadline by.

And deadlines work both ways, a task is very rarely completed before it’s deadline.

Kinds of Deadlines

Real Deadlines

If a task is not completed by a certain time someone will die. This kind of task is really common in novels and movies. A clock is ticking and if the task is not completed by the time the clock reaches zero, BOOM!

If have never seen this kind of deadline in software development, but they may exist.

Planning Deadlines

Some deadlines are set in order to simplify planning. In the large Death March projects, the plan is to show the project at a certain date. In integration projects, the deadlines are set to be able to synchronize with other teams working on the same product.

This kind of deadlines are actually understandable, but I am arguing that they actually slow down projects by introducing stress, which introduces bugs. The bugs introduce bugs in the dependent projects, and slows down many projects instead of just one.

Motivational Deadlines

Motivation deadlines are set to get people to work. The assumption is that if a deadline is not set people will procrastinate over different ideas, or just slack off since there is no date set for the release anyway.

This is, absolutely, the worst kind of deadline. If the team is not motivated enough to do a good job without a deadline, you need to get a new team, not set a deadline.

Why Deadlines Are Bad


Consider walking on a one foot wide plank. If it is on the ground it is easy. If it is two meters up it is difficult, but if you put it at twenty meters it is a whole different ballgame. That is what its like with deadlines, they put an unnecessary pressure on people.

Loss of Motivation

Work consist of whatever a body is obliged to do, and play consists of whatever one is not obliged to do. — Mark Twain

In his book, Drive, Dan Pink differentiates between intrinsic motivation and extrinsic motivation.

Extrinsic motivation is motivation driven by carrots and sticks, rewards and punishment. It works well for simple, well-defined tasks.

Intrinsic motivation works well for creative, ill-defined tasks, like programming.

Intrinsic motivation is fragile, it disappears in the presence of carrots and sticks. A deadline is a stick, whether set by ourselves or someone else.


A liveline is, quite simply, a task that is done. When a task is done, it is easy for others to use it, in their plans or in reality. If we want to build a stable house, we should build it on stable ground.

When using livelines the iteration length is the same length as a task. This is usually a lot shorter than the usual one to four weeks common in Scrum and other agile methods. It also leads to variations in the iteration length.

If you implement your task all the way into production, you get Continuous Deployment or Continuous Delivery. This puts a lot of pressure on your tooling and on automation but, I believe this is the way to go.

It is 2010, it is time to get rid of deadlines.


  1. I like the spirit of this article, but I think you’re underestimating the importance of “Real Deadlines”. Not the kind where someone’s going to die, but how about:

    If our trading systems aren’t compliant with new bank regulations by Date X, we’ll be fined $100,000, kicked out of the exchange, and lose a huge number of customers.

    We need to adapt to our biggest supplier’s ordering system by Date Y, or we won’t be able to get the parts we need to build our widgets, meaning we’ll have nothing to ship, will have to shut down the factories until it’s resolved, etc.

    I have *absolutely* seen these kinds of deadlines in software development. They may be the exception rather than the norm, but they’re very real. Heck, you even called them “Real Deadlines” yourself :) Otherwise I agree, planning and motivational deadlines should be avoided.

  2. For me, it seems like this idea of no deadlines means no project budgets as well (since time is money), at least if the project has a fixed size. I still like the idea though.

  3. Anders Janmyr

    @Jack, Point taken. But, even though there is a Real Deadline in the future, there is no need to pack the tasks leading up to the Real Deadline with guessed deadlines.

    @Gustaf, I disagree with the notion, that “time is money”. Time is limited, money is not. But, guessing a time limit for a task may force me to do a bad job, thus devaluating my time.

  4. My current dev team has been working within the scrum framework for a year, using 2 week sprints. That means that we have a “deadline” every 10 workdays.

    This kind of deadline does not introduce stress at all, in my experience – quite the opposite, compared to how we used to work. We do a best effort plan (the whole team estimates) for what we can manage in the sprint, and we have a written down, agreed upon definition of Done. If it becomes obvious that we’ve underestimated something, lower priorite backlog items are either removed (postponed) or items are scoped down, if they can be and still deliver business value.

    There’s no panic scramble to try to reach what we obviously can’t. The pace needs to be sustainable.

    I find these deadlines helpful because they mark clear progression steps, and as long as you remember that estimation remains guessing and don’t elevate those deadlines to be what it’s all about

  5. Anders Janmyr

    @ Cumbayah I’m happy it works out well for you. My experience is different. We often scrambled to manage the tasks that we had estimated two weeks before.

  6. @Anders Janmyr & @Cumbayah I’ve worked as a Scrum Master at two different companies. I totally agree with Anders that “my experience is different”.

    At my past employer I began questioning the Scrum way together with my team, and managed to transform our process to a flow based kanban one, which worked out much better.

    All time spent making guesstimates and doing/redoing burndown charts is much better spent developing software IMHO.

  7. Rob M.

    Deadlines are convenient in business and helpful in education, but deadly for creativity. Anyone who understands the creative process has probably experienced being forced to push out undeveloped ideas under pressure. The task may be completed, but the motivation gets destroyed in the process.

    The designer lives for watching the brush flow across the canvas. Scraping it across as quickly as possible is a job for machines, not for humans.

Trackbacks for this post

  1. Tweets that mention No Deadlines — Jayway Team Blog --
  2. Dynamic FTP Client Using Apache Camel | Allen Solly

Leave a Reply