For clarity, a deadline is:

A time limit or deadline is a narrow field of time, or particular point in time, by which an objective or task must be accomplished.

From wikipedia

My whole software development career I have been doing "Agile" which everywhere has seemed to mean at least the following practices were adhered to:

  • Weekly or Bi-Weekly sprints
  • Retrospectives Sprint planning
  • A product owner
  • Scrum
  • User Stories

However, every project I have ever been on has insisted on setting a deadline. Given that Agile attempts to focus on adaptive planning, flexibility and change; are deadlines Agile?

My own opinion is that they are not, as I see deadlines leading to a lack of flexibility and lack of quality. Instead, I think it provides more value to focus on Sprints and early deliveries. It seems however, in every circle I have been in, this is not the case, and deadlines are viewed to go hand in hand with Agile development.

  • 37
    Isn't as sprint a deadline?
    – JeffO
    Commented Feb 23, 2015 at 20:34
  • 13
    @JeffO a Sprint is a commitment, which shifts based on the velocity of your team. Deadlines are IMO, commitments without honesty or transparency to the client. They do not take into account velocity or the multitude of other risks that go into making software projects.
    – stevebot
    Commented Feb 23, 2015 at 20:42
  • 8
    I would say that delivery each sprint is non-negotiable. You assess the work, you put card sizes on it, and you load up enough to keep your team busy until the sprint ends (and the sprint should be small -- anything from a week to a month). "Delivery deadlines" should be based on historical trend of completed work against anticipated work. Agile adds/removes nothing from the old "cost/time/scope" constraint idea, it simply uses scope as the preferred method of managing slippage on the basis that better prioritization against scope is generally preferable to spending more money or time.
    – Calphool
    Commented Feb 23, 2015 at 21:26
  • 9
    Here's Ron Jeffries' (one of the original authors of the Agile Manifesto) take on deadlines: xprogramming.com/articles/jatmakingthedate
    – Jules
    Commented Feb 23, 2015 at 23:38
  • 5
    Some of my deadlines have proved pretty agile.
    – psr
    Commented Feb 25, 2015 at 21:39

15 Answers 15


Deadlines are a reality. Most times you have to have something by a certain date. It's unavoidable. Without deadlines, even agile projects can succumb to Parkinson's Law:

Work expands so as to fill the time available for its completion.

In other words, if your project can go on forever, it will.

In relation to deadlines, Agile tries to do a few things:

  • Ensure that everybody can always see how much work will get done by the deadline
  • Ensure that the most important features are completed first
  • Ensure that the completed features are usable, in the sense that they don't depend on features that haven't yet been completed
  • Ensure that development continues at a sustainable pace

That way, when the inevitable day comes, you don't have a useless pile of code, but a working, tested product with, hopefully, only the least important stuff unfinished. And nobody is surprised by the finished product.

So yes. "Agile" and "deadlines" can be perfectly compatible.

  • 10
    @stevebot That's exactly the situation that prompts Parkinson's Law. I've never met a client that can't think of more features to add. Without deadlines, the feature list, and thus the project, is infinite.
    – Eric King
    Commented Feb 23, 2015 at 20:30
  • 12
    @stevebot I think we understand each other, but have different meanings of the word "deadline". To me, a "deadline" is a specific date. To you, a "deadline" is a specific set of features promised on a specific date. I believe my definition is the more common usage, and my answer is based on that definition. Judging by the other answers you've received, others agree with me. Take it for what you will, I won't be offended. :-) But my answer still stands.
    – Eric King
    Commented Feb 23, 2015 at 21:17
  • 5
    " There will always be expectations and its always possible that your teams velocity causes you to miss the most basic of features." If you're implementing agile properly, then that statement is an absurdity. Your backlog MUST be prioritized according to maximum customer value. If it's not, FOR WHATEVER REASON, then you're not practicing agile. You're practicing something else.
    – Calphool
    Commented Feb 23, 2015 at 22:36
  • 7
    "We have to have something to ship by the 28th of July." The deadline in this sentence is the 28th of July. You can have the "something" be a predetermined set of requirements, or it can be whatever is ready. The "something" part is not the deadline. The date is the deadline.
    – Eric King
    Commented Feb 24, 2015 at 15:10
  • 5
    @stevebot "(The answer) misleads the reader to believe that Agile + Deadlines = perfectly fine." That's the point, though. Agile is perfectly fine with deadlines. Or without. Take your pick. To say otherwise is basically saying "Well, since we have a deadline, we can't do this project as agile!" which is baloney. I've worked on many projects that have both had deadlines and have been "agile". Are deadlines agile? Well, they're not not agile.
    – Eric King
    Commented Feb 24, 2015 at 22:03

Deadlines are a fact of life. There are things that have a very firm date.

We need the software by Comdex


The games must be on store shelves by Black Friday

and the like. One cannot postpone Comdex or Black Friday - the rest of the world doesn't work that way.

The goal that Agile has is that things that won't meet the deadline fail faster (and that is a good thing), or the scope is able to be re-examined sooner so that the resources can be focused on the correct ROI in a more timely manner.

The deadline is a hard date that is set down firmly. Agile is a tool that allows one to realize earlier in the cycle that the software is going to take twice as long to develop as originally hoped. It is important for project managers to be able to realize these issues earlier than later so that either more resources can be added, the scope changed, the deadline adjusted (in the situation where it is a firm rather than rock solid deadline) or the project canceled.

The transparency that Agile seeks is that of showing the problems and progress earlier in the cycle. The classic waterfall delivery failure is one were you've spent months behind closed doors and deliver the product a week before the deadline and are told you're doing it all wrong and you've wasted months (and now have completely blown the deadline). The other classic waterfall failure is finding out a week before the deadline you've still got months to go. Agile seeks to make these issues known early in the process.

The other part that Agile seeks to do in the context of a deadline is that even if only part of the agreed upon features are complete (for whatever reason), the current version of the software is useful and deployable.

Ok, we missed having everything we want for the tax software to be deployed on April 15th, but we've got 75% and what we do have works and has been working since we started last November. We've known we are not going to be able to deploy the full feature set since mid December and refocused our efforts on the 80% of the customer base.

  • 2
    I agree with you, though I would flip the importance of your two assertions. #1. Agile is primarily focused on making sure that the current version of the software is useful and deployable. #2. Secondarily, it helps us realize when scope is completely unreasonable earlier so that product owners can reprioritize and maintain the goal of #1.
    – Calphool
    Commented Feb 24, 2015 at 18:31
  • 2
    @user40980 This is horrific. Yes, there are things that have a firm date. however, you cannot produce an infinite amount of work in a finite amount of time. Deadlines can't be Agile except when they're only produced after estimation. That's an extremely important caveat. That's why you plan a sprint -- to determine exactly what work can be completed. A hard, fixed deadline by which everything must be complete in spite of effort cannot EVER be Agile.
    – EKW
    Commented Jul 4, 2016 at 19:14

Some deadlines must be met. Contractual obligations, conventions, regulatory requirements. Some are imposed by managers who want to be able to put software development in the same chart as manufacturing on their spreadsheet. Whatever the cause, most people can't get away from them.

If you are working in a functioning team then communication between the developers and management/stakeholders means that the people who need to make a decision are well informed to decide if missing the deadline or continuing with development is more important.

Even if you are delivering completed user stories once a week, or twice a month you will still probably have deadlines. When one is coming up, make sure your stakeholders know what you think will fit in by the deadline and set expectations.

If you are constantly building the best software you can with the requirements you currently have at every stage, then a deadline at the end of any sprint should theoretically not be a problem. Practically, this isn't normally the case, but then neither are deadlines that appear out of thin air. Most important deadlines I've ever been given were communicated to me long before, it was the expectation of the quality and the features that were the issue. All the deadlines I can think of that have come out of nowhere are because of lies. Either sales told a customer the feature was there or could be added without consulting and sometimes without even informing engineering, or someone told their boss it had already been done.


If someone wants to set a deadline then that is fine and the deadline can be fixed, but what they must understand is that if the deadline is fixed, then the scope must remain flexible.


In an ideal world we wouldn't have deadlines and just deliver things when they are ready. The reality though is that people paying for things usually want to know when they are done. Agile methodologies do recognise this but also recognise that not everything can be tied down.

This ensures that you can keep quality of delivery at the level that is right for the product. If you fix a deadline and scope (and budget) then things get rushed and you end up back in the old waterfall world with a crazy crunch time at the end of the project. Increasing the budget usually isn't the answer, because adding more developers and testers doesn't solve a problem faster. It's a well-known view (and I agree with it from experience), that the more people you add (each with their own foibles) the more time it takes.

Now, typically (unless they really understand Agile methods) the person paying for the software doesn't like being told, we can meet your deadline but we can't do everything you want. This can be managed by prioritising the features that make up the software. Your prioritisation discussion might go like:

Dev Team (D): "Please can you prioritise the features you want delivered, with most important first?"

Customer (C): "Everything is priority 1 - I want them all done by the end of next month."

D: "That may be possible, but that may not be possible if requirements change or we discover issues we didn't expect while going through development."

C: "Well what if I give you more money?"

D: "sigh...even with more resource it's going to take them one month to really get going; so if you're not sure how to prioritise the features just tell us which ones you want done first."

C: "Ok I want the big button but make it really big, and then ...etc"

Now you can start working through the features in priority order. It does help to also look ahead with your team to those items lower in the priority order and make some early estimates, knowing you may change them when you get to development when you have more information. This can be used to redefine or create your roadmap if you don't have one yet. This then forms the basis of your release plan. The roadmap can be discussed with the customer acknowledging that scope may change but you do have an order of things to be delivered.

One of the great advantages of Agile is that it acknowledges that things change as you go through development and you adjust as they do. Contrary to more traditional approaches, this principle, in conjunction with the regular sprint deliverables and ongoing communication with the customer, mean that you are naturally forced to be more transparent about progress, which is a good thing.

Sometimes the customer doesn't like that they will not get what they want by a certain date BUT they will understand why and what they do get will be of good quality. And 6 months after features are delivered the customer won't care or remember that you delivered by a certain date, they'll remember the quality of the product that they are still using.

  • 11
    "So if someone wants to set a deadline then that is fine and the deadline can be fixed, but what they must understand is that if the deadline is fixed, then the scope must remain flexible." Absolutely.
    – Eric King
    Commented Feb 23, 2015 at 21:05
  • 3
    This is probably the most agile answer on here. The fact that it doesn’t have many votes is testament to how widely misunderstood agile is. Commented Nov 18, 2018 at 9:51

Arbitrary deadlines that have no consequences if missed aren't very agile, but there are situations where for reasons outside of the development team's control deadlines must be set and kept. Fortunately, if the deadlines are reasonable there are plenty of ways to invert the equation and handle deadlines in an Agile way.

Deadlines aren't always wrong. As we all learned from Obi-Wan:

"Only the Sith deal in absolutes"

It's fair to say that in most cases deadlines are silly, unnecessary, and certainly not Agile, but it would take a fool to say that this is always the case. The architypal case is software needed for a time-sensitive use, such as election tracking software. If the software isn't ready in time for the election, it wouldn't make sensible nor practical to postpone the election, and it doesn't seem to be very customer oriented to just say 'Sorry, looks like we took too long. I know this software you're paying us for is completely worthless, but deadlines aren't Agile so how can you really hold it against us for not meeting them?'

It's not very Agile to tell your customers to shove it for wanting something that is time-sensitive, and at the end of the day somebody is going to have to build these things. So how can we still make the customers happy and still deliver seemingly reasonable solutions to things which are time sensitive? Well, if developing software takes an uncertain amount of time, and the deadline isn't variable, something else will just have to be variable to handle that uncertainty...

If the delivery date is held constant, some other aspect becomes a variable. As we all know, there can be a wide amount of uncertainty in software projects. Something has to be made variable in response to this uncertainty if you want success in your project, and usually that is the delivery date. It seems natural enough, anyways. But that isn't your only option. If you're stuck committing to a hard deadline, the way to handle that is to make your delivered features variable. Prioritize a list of features, communicate clearly that there is uncertainty in the amount of features that can be delivered by that date. Work with the customer to prioritize these features so that the most important ones will have a higher likelihood of being shipped. Then, it's business as usual, only when the deadline rolls around you ship whatever is ready to be shipped. In this model, shipping more features is the analog to shipping at an earlier date, and shipping fewer features is the analog of shipping at a later date.


Deadlines are traditionally based upon the business lifecycle. Tax software needs to be in by April 15th. Reporting for the next fiscal year might need to be done by July.

The Agile manifesto states:

Individuals and interactions over Processes and tools

Working software over Comprehensive documentation

Customer collaboration over Contract negotiation

Responding to change over Following a plan

Deadlines are a contract. They are a plan. They do not respond to your team's velocity. They do not change if you lose your three best developers.

Deadlines are not Agile, but Agile can give us feedback on deadlines. Agile let's us know if our velocity will not let us make a deadline without a feature being cut. It also let's us know if we need to hire to make a deadline. And in some cases, it let's us know that a deadline is impossible, when there are no features left to cut.

The best thing an Agile team can do, is let their velocity and prioritized backlog drive the deadlines. This will give estimated delivery dates. If those fall outside the deadline, then its time for a serious talk with the client and determine if the deadline is even doable.

  • 1
    Sometimes, you have to ship by a certain, non-negotiable date (a deadline). In that case, the best thing that an Agile team can do is let the deadline drive their backlog, giving the estimated feature-set at the deadline. If this estimated feature-set fails to meet the client's requirements, then it's time for a serious talk with the client and determine if the project is even doable.
    – Eric King
    Commented Feb 24, 2015 at 22:20
  • @EricKing yes, you are right, Agile can work with deadlines, I think I have been reading your statements as "deadlines are Agile" instead of "Agile works with Deadlines."
    – stevebot
    Commented Feb 24, 2015 at 22:25
  • Thanks for your comment. I think we've both been talking past each other for a while, and maybe it just takes a certain phrasing to make things click. I haven't been meaning to say "dealines are agile", but I can see how it would come across that way. Sorry about that.
    – Eric King
    Commented Feb 24, 2015 at 22:30

I would say that delivery each sprint is non-negotiable. You assess the work, you put card sizes on it, and you load up enough to keep your team busy until the sprint ends (and the sprint should be small -- anything from a week to a month). "Delivery deadlines" should be based on historical trend of completed work against anticipated work. Agile adds/removes nothing from the old "cost/time/scope" constraint idea, it simply uses scope as the preferred method of managing slippage on the basis that better prioritization against scope is generally preferable to spending more money or time.

Some people seem to confuse agile for "wild west". Agile doesn't mean anything goes. Agile means that we stop lying to ourselves about how well a reasonable person can estimate. Basically we can estimate software development about 2 - 4 weeks into the future. Beyond that, it's all varying degrees of swags and guesses. Worse yet, the cost of providing estimates for things further and further out into the future approaches the cost of just doing the work. For whatever reason, Project Managers have historically been unwilling to admit these absolute truths to customers. Agile simply adjusts that thinking by asserting that there is a limit to how well we can predict the future in software engineering, and makes a subtle switch to "evidence based estimation" for long term forecasting. By giving dead certain delivery in small chunks, and evidence based delivery for long term stuff, we get something close to the best of both worlds -- we get to be truthful about what we actually are capable of estimating, and we can provide fairly reasonable estimates of long term future delivery based on what we've been delivering so far.

  • BTW, Cal, i pretty much agree with everything you're saying here. and i do not think that it contradicts what i wrote. Commented Mar 10, 2015 at 16:26


Are deadlines [a]gile?...[D]eadlines are viewed to go hand in hand with [a]gile development.

Many answers here are likely to focus on the engineering aspects of the question. Instead, I will address this from a project management perspective.

A deadline implies a great deal of up-front planning which is not in line with agile principles. Instead, iterative development models rely on time-boxes, cadence, and release cycles that include just-in-time planning, but not the "big, up-front planning" that is generally associated with traditional project management deadlines.

It is still possible to do release planning with agile methodologies, but the plans are generally based on an estimate of the number of iterations required to meet a goal rather than management targets set by fiat. That isn't to say that shipping dates can't be set, or that goals can't be met, but the way that they are defined and met is quite different than in traditional project management methodologies.

Think Time-Boxes, Not Deadlines

However, every project I have ever been on has insisted on setting a deadline. Given that Agile attempts to focus on adaptive planning, flexibility and change; are deadlines Agile?

This is a common misunderstanding of the agile principles. Agile frameworks such as Scrum and Kanban are not focused on deadlines, but rather on time-boxing and a sustainable cadence of delivery.

In Scrum, for example, the Sprint is not a "deadline." It is a time-box which is filled with the amount of work the team estimates will fit within the time-box without overflowing it, and is then either "done" or "not done" when the time-box expires. Once gone, the time-box is gone forever; any work that is not done must be re-planned and re-estimated within a new, equally ephemeral time-box based on then-current (rather than historical) needs of the project.

The importance of the time-box is that it creates both a predictable cadence for stakeholders to review progress, and a sustainable pace for the team in which to deliver potentially-shippable increments of value. The work is incremental, and follows the cadence; the concept of a big, up-front deadline is therefore not in line with agile principles.

Release Planning Based on Time-Boxes

Perhaps the one area where people have the most difficulty mapping agile processes to traditional frameworks is in release planning. Release planning often involves either fixed-scope or fixed-date deliverables. In agile frameworks, release planning is usually done through an estimation process where scope is explicitly defined as a mutable variable, while release dates are estimated in iterations.

For example, a project may be committed to releasing v1.0 of a project at the end of 20 iterations; the scope of what is released may change over the life of the project (as scope, features, and priorities can change at the start of every Sprint), but the target dates for each release is fixed in the project plan. The team strives to deliver a potentially-shippable increment each Sprint, and the Definition of Done includes quality checks such as continuous integration to ensure that the project is in a releasable state at the end of each Sprint.

Occasionally, you will see agile projects where the scope is fixed, but because scope is the mutable variable in agile projects, the release date may change over time as the scope of each iteration adjusts, changes, or adapts to the evolving needs of the project. I certainly don't recommend the fixed-scope approach to agile teams, especially inexperienced teams, but there are times when it's the right approach.

See Also

  • ...sort of... but over time the team better be focusing on getting the mount of work to fit those "time boxes" well. If you just accept that your time boxes and work completed are unrelated, then you're doing cowboy coding, and it's completely unpredictable. I would say that perhaps it starts as "time boxes" and over time it becomes a somewhat non-negotiable deadline as the team gets better at predicting how much work they can handle in a sprint. It's about a team self-training to become excellent at short-term estimation, because that's where predictability comes from.
    – Calphool
    Commented Mar 6, 2015 at 16:18

Think of deadlines as commitment. The fact that the project is agile doesn't mean you shouldn't commit to deliver given features for a given date.

What agility brings is what happens in between. Instead of having a strict software requirements specification document which defines that you should deliver feature A composed of sub-features B, C, D and E for a given date, you commit to deliver the feature A for a given date, given that at the early stage, neither you nor your customer knows what the feature will look like, or would it have sub-features B, C, D and E or maybe B and C, or a dozen of other sub-features.

Imagine a company which previously delivered goods to small companies only and have just signed a contract with a large corporation. This large corporation uses EDIFACT, and it appears that the current accounting software used by your company doesn't handle EDIFACT. You're requested to create a plugin which does that, given that contractually, your company should be ready for April 15th.

The agility would mean that intermediary steps will be delivered progressively, and be based on regular feedback. Basically, you'll show your progress to the accountants, and they will tell you what they think about it, what are the possible issues, etc. This also means that maybe originally, accountants had a great idea which, they thought, could improve substantially the user experience. Three weeks later, it appeared that not only it doesn't improve it that much, but it will also result in one month of additional development. Thanks to Agile, you can then redirect your efforts from this feature to something else, making sure to deliver on time.

You should also understand the point of view of the customer:

  • Often, businesses need a specific delivery date. For instance, you can't deliver the Olympic games online streaming service after the end of Olympic games. Business-wise, this is simply a failure, with huge negative consequences.

  • Without having a commitment, it is tempting for a developer or a subcontractor to either be perfectionist or make the project low priority. While the regularity of the sprints help, it doesn't totally prevent this risk.

    I'm not fond of deadlines for that, especially since deadline slips happen very easily, but I still understand why many companies do that. It is not always easy to see that the project is behind the schedule by looking only at the sprints: a missed deadline, in this context, may be a clear reminder that something goes out of control and should be dealt with, right now.

  • Thanks, but why is it that the regularity of sprints doesn't totally prevent this risk? Also, I like your example of the Olympic Games, but I think a requisite is that scope and cost and not bound. If I put one developer on that project and was required to deliver all features, the deadline would not really help and would most likely drive us to deliver a very low quality product.
    – stevebot
    Commented Feb 23, 2015 at 20:32
  • The regularity of sprints doesn't prevent the risk because it's relatively easy for a manager to trick the stakeholders to think that the project is going just fine. Things like “We didn't implement this thing because you've put an accent on those two things during our last meeting.” or “Two of our developers are on vacation, so we did only half of the job during this sprint.” are difficult to argue about for the stakeholders, and in every sprint details, they may lose the overall picture of the project. Commented Feb 23, 2015 at 20:38
  • then you have a problem with transparency and putting a deadline on top will not help. Those excuses will just as easily be thrown at the deadline too and this is almost always what I see happen in real life.
    – stevebot
    Commented Feb 23, 2015 at 20:39

eXtreme Programming states about release planning:

The base philosophy of release planning is that a project may be quantified by four variables: scope, resources, time, and quality.

Which seems fair. It also states that

No one can control all 4 variables. When you change one you inadvertently cause another to change in response. Note that lowering quality to any less than excellent has unforeseen impact on the other 3 variables

And as already noted by br3w5, increasing resources is a bounded solution. You can probably add a couple people that were already part of the team if they were dispatched on something else. But you cannot simply increase the team size fast and indefinitely, at least not without team re-organization which takes lots of times.

So, with irreducible quality and fixed resources: a deadline being a time constraint, it means you need to adapt scope. And using agility gives you the mean to meet the deadline with the most productive scope possible. However, you can usually guaranty that some part of the scope will be done in time. This is the part that you can trustfully estimate its time to be bounded below the deadline. Typically something that is really close to what you have done several times and has little unknown.


Deadlines are not agile, they are:

1)Waterfall, and 2)Wrong.

Software and deadlines do not work well together and never have. In many ways, the Agile methods are a reaction to the massive problem of missed deadlines or software which was abandoned when it became clear that the deadline could not be met (as well as budget issues, too).

Agile attempts to inject reality into the situation by saying "You know the deadline or the features are going to slip and/or change, we know it, so let's get off on the right foot and not even pretend".

The key is that the deadline becomes simply a release date for the first version of the software. That might still be written in stone - say, the software is for academic use and MUST be usable by the start of term - but what you will deliver is not. You have a minimum viable product that everyone is very sure can be delivered by then, and you have a load of "would like to haves". Instead of everyone throwing up their hands when it turns out that the entire list isn't going to be delivered by the "deadline", you make sure you get the MVP out the door and as many of the "would like to haves" as possible and then assess the cost/benefit of the remainder at that point.

Anyone who's played computer games for any length of time knows exactly how this works! If the first release is up to beta standards many gamers are happy, so low are the expectations of what "firm, real deadlines" mean in real life.

So deadlines are not agile, they are holdovers from the days when people thought that software could be treated like hardware and steel engineering. We've learnt that this is neither possible nor desirable, since it throws away the greatest advantage software has over hardware: it is soft.

Agile tries to exploit this softness by allowing goals to develop and change over the course of the project in a way that a bridge design never could.

  • 4
    I have no clue why people downvoted you. I've been doing agile/xp app dev for over 10 years in a Fortune 100 company -- introduced it here as a matter of fact, and I see absolutely nothing wrong with what you said. I upvoted you back to zero, because whoever downvoted you has to be an agile newb still clinging to their old reality for God knows what reason. People are too simplistic. They think that "Software and deadlines do not work well together" is an absolute. You aim to hit EVERY sprint deadline. You just don't lie about your ability to hit long range estimated dates. It's that simple.
    – Calphool
    Commented Feb 24, 2015 at 18:20
  • 7
    @Calphool I have issue with saying that deadlines are waterfall (they exist no matter what methodology is used - they even exist for cowboy coders) and wrong (they exist because of external constraints of time - no more wrong than "we have to have this code run on that hardware with some minimal performance"). It is a time constraint on what an acceptable solution is. Filing taxes by April 15th is a deadline. Having the software to the distributor by Nov 1 so that it can be on the shelves by Nov 27 is a deadline. Neither of these are wrong.
    – user40980
    Commented Feb 24, 2015 at 19:31
  • 4
    @MichaelT: If you haven't already, I'd suggest you read Tom & Mary Poppendiecks' book "Leading Lean Software Development: Results Are Not the Point". He's simply conveying a fairly popular meme in lean/agile circles. If you and your team are focusing on deadlines more than you're focusing on continuous improvement, you're not really living agile. You might be doing scrum, but not living agile. Do long term deadlines exist? Obviously. Are they what agile teams should focus on? Absolutely not. Deadlines are incidental to agile thinking.
    – Calphool
    Commented Feb 24, 2015 at 19:46
  • 4
    @MichaelT The OP referred to project deadlines and that's what I'm responding to - long term deadlines set by a PM at the start of a project rather than a sprint. Certainly there are deadlines of a sort in agile, but they have a very different nature to what people typically mean by project deadlines, but maybe it's just semantics that's the problem here.
    – Nagora
    Commented Feb 24, 2015 at 19:54
  • 3
    @Ellesedil: Tell me your most important feature, or your minimum marketable feature set, give me a few weeks to a few months to build up a track record against your desired feature set (varies depending on how much you're asking for -- it takes more time to predict how long it'll take to get to the moon vs. Pittsburgh). Then I'll tell you, and since my estimate was built on actual deliveries of useful software, we'll be able to bank on the estimate, unlike the fairy tale you're forcing me to give you at the outset.
    – Calphool
    Commented Feb 24, 2015 at 21:22

The purpose of software development methods, when understood correctly, is to make us more productive by focusing our thoughts, and to provide a common language for typical situations. It's about inspiration and enabling, not about mind control and guilt.

Following a software development method literally with no compromises whatsoever corresponds to what is called radicalism or fundamentalism in other contexts. The pure form of this aberration is rarely seen in practice because it typically leads to rapid failure in the market. But of course when developers compete in the hard task of implementing a specific method, overshooting the mark is a natural occurrence.

The problem is exacerbated by the fact that missionaries and evangelists primarily target those who still need convincing to use the method at all; and even if they do preach moderation, human nature ensures that it gets less attention.


Answer "probably no"

The Project_management_triangle states that cost, time and scope (and also quality) depend on each other. ("pick two and get the 3rd")

A scrum sprint chooses fixed time (i.e. 7 days=length of sprint) and cost (i.e. budget for 7 team members) and estimates the scope (the number of stories to be done in sprint)

If management or sales-department tries to define all three (cost, time and scope) then it is not agile in the sense of scrum because the team cannot cannot promise to reach the goal (without violating quality=definition-of-done)

Professional management tries to define cost and time and reduce scope if necessary if there is some fixed date to be met.


Can this not be answered simply and directly?

No deadlines are not agile.

The whole point is to build what you can in an iterative fashion learning and adapting as you go.

A deadline is "you have to deliver x by y" which fails on both counts in that you're promising a fixed deliverable in a pre-determined timescale (where agile says we're not sure what we're trying to deliver, and the learning from agile teaches us that even if we do know its very difficult to have certainty about timescales - or its a solved problem and we shouldn't be doing it anyway).

Having established that the answer to the question is "No, deadlines are not agile" - then we are able to have an interesting conversation that addresses the question of "how do we address deadlines in an agile context" and there is a lot of good thinking about that in the other answers.

To my mind a reasonable answer to the latter is that we will deliver increments of value early and often and we will see where we are in due course - but there is no one size fits all.


The degree of agility required in one's work is inversely proportional to how high their position is on the organization chart.

"Agile" is good, for what it is. "Agile" sorta means "open-minded coupled with sufficient competence." It's the grunts at the bottom that have to be the most agile.

If, at management levels, the pointy-haired boss was agile enough to understand that pushing a deadline back a week will make for a better product, or will make for cleaner, more bug-free, and more leverageable code so that the company (or the division) saves two weeks in the future, that's an agile deadline.

But like enlightened self-interest, it doesn't really exist.

  • 5
    A deadline that can be moved isn't a deadline. That's called a calendar date. Deadlines are things like Black Friday - either it's in store or it isn't. Still, Agile means I have the best I can have by that deadline.
    – MSalters
    Commented Feb 24, 2015 at 0:19
  • so, if it misses that deadline, but it's in the store the following week, does the manufacturer always die? missing that deadline incurs cost. but what if that cost is more than made up for with a better product, that impresses customers more with their first impression ("you never get a second chance to make a first impression") and has other benefits that exceeds that cost? if management is smart enough to make a tactical decision to defer release (it's bumping the deadline, not ditching it) to the benefit of customers and manufacturer alike, ain't that "agile"? Commented Feb 24, 2015 at 4:14
  • Have you ever had Black Friday deadlines with Walmart? The feeling I got was that if you screwed up this year, you won't get a second chance next year. That's literally "no second chance".
    – MSalters
    Commented Feb 24, 2015 at 7:59
  • 3
    listen i code in the audio and music instrument area. certainly the product has to get out the door in order to make money with it. but deadlines have literally caused some ill-developed crap to go out the door that the customers, company, and future developers were forced to live with for years after. Commented Feb 24, 2015 at 15:14
  • 5
    The thing with Black Friday sales is that it's a marketing attempt to create a false scarcity of time and product in order to get people to behave irrationally and buy things that they otherwise wouldn't. This example of induced irrational behavior doesn't seem to be all that different to some approaches to software project management. In arguing that creating false scarcities of time with software is not a good idea, I'm not saying that real scarcities of time are impossible because they obviously are in some contexts (and are crucial at that).
    – shuttle87
    Commented Feb 24, 2015 at 17:56

Not the answer you're looking for? Browse other questions tagged or ask your own question.