I tend to think they do as long as the scope is variable and not fixed where the idea is to deliver value based on the time you have. Am I correct in my assumption?

  • 2
    Absolutely correct. Commented Jan 18, 2018 at 10:19
  • 1
    Not to be “that guy”, but could expound on the definition of “deadline” in the context of this question?
    – Josh Bruce
    Commented Jan 19, 2018 at 4:05

5 Answers 5


I think of a deadline as a date for which, if you miss it, an opportunity (or a person, or a project, or an organization) dies.

For instance, we once had to get a newspaper site's galleries ready in time for the Oscars. Failure to do so would have meant we missed our opportunity to put up pictures of the stars in their beautiful clothes. The Oscars wasn't moving for us! Similar deadlines I've encountered are Christmas, summer sales, and the end of the academic year / exam marking deadlines.

In these situations, scope needs to be flexible; whatever is ready in time gets shipped.

However, a lot of companies seem to also have something I call sadlines. These have often been created around estimated scope, with or without development team involvement. Nothing and nobody will die, but if you miss them, someone will be sad. Their reputation is at stake, or dependencies within the organization have been managed around them.

Bizarrely, people tend to behave very pragmatically around deadlines in a way that they don't around sadlines. The appearance of meeting a sadline is often more important to sponsors and stakeholders than actually shipping something valuable or high-quality.

At that point you'll find you have fixed scope and fixed deadlines, no matter what kind of methodology the team says it's using.

This is a common pattern I see in projects where Agile's been adopted at a team level, but the organization itself is still transforming, and it's not yet safe for middle managers to say "no" to requests or to adapt their plans based on new information.

Note that this is an anti-pattern. It shouldn't happen on Agile projects, which have plenty of ways of dealing with it... but it often does.

Scaling and transformation methods are intended to help solve this, amongst other issues. It's usually outside of the influence of an individual project manager's ability to effect change, though telling the stories and providing evidence to those who can make change happen can help.

  • 1
    I love the term "sadlines." Did you coin that? I want to add that one to my coaching vocabulary!
    – Todd A. Jacobs
    Commented Jan 20, 2018 at 23:20
  • 1
    Yes, I did. Please share it as widely as you would like!
    – Lunivore
    Commented Jan 20, 2018 at 23:21
  • Thanks as I thought. I have encountered members within the community who feel that commercial deadlines should be ignored when delivering agile projects, since 'deadlines' do not exist in an agile project.
    – bobo2000
    Commented Jan 21, 2018 at 19:49
  • If it's a genuine deadline, and they're talking to their business stakeholders like they're meant to be doing, they will very quickly be re-educated.
    – Lunivore
    Commented Jan 21, 2018 at 23:52
  • "The appearance of meeting a sadline is often more important to sponsors and stakeholders than actually shipping something valuable or high-quality." FTW Commented Jan 25, 2018 at 16:08


Do deadlines exist in agile projects?

Yes and no. A lot depends on your framework, and on your team's accepted definition of deadline.

What is a Deadline?

Historically, the term "deadline" was literally a line beyond which prisoners would be shot. In business, a deadline is both an expected delivery date and the point at which Bad Things™ are expected to happen if that delivery date hasn't been met.

Hard deadlines (as opposed to arbitrary targets) often result in lost business, lost revenue, lost jobs, or other unhappy results. However, a generic deadline is any time or date by which something is supposed to be completed. The problem is really when a process doesn't differentiate between the two uses of the term.

Deadlines as Delivery Targets

Scrum uses time boxing, and you could certainly consider the end of each Sprint a deadline by which something ought to be done. Dependencies within a Sprint and between tasks also generate deadlines. While a team may miss its forecast or fail to meet a Sprint Goal, this should be considered more of a learning experience and an opportunity for process improvement than a traditional Bad Thing™.

Other agile frameworks such as Kanban aren't driven by time boxes. An incomplete task in Kanban is either waiting, running, or paused; while people certainly have expectations about how long a typical job may take, this is usually a schedule forecast based on past performance rather than using the targeted delivery dates often referred to as "deadlines."

The general agile practice of decomposing stories into tasks of 1/2 to 2 days in length can also create deadlines, but this is more of a guideline than a hard requirement of any particular framework. I'd call that completion target more of an expectation than a hard deadline, but others might argue with that.

Semantics Matter

There's a reason practitioners of frameworks like Scrum use terms like time box, iteration, and forecast rather than loaded (and often overloaded) terms like deadline. While the word deadline isn't wrong, it often carries a connotation of "or else" that isn't really aligned with agile principles.

If you find yourself using the term deadline in an agile context to identify expectations or consequences for the project, you may want to take a closer look at how you're communicating about the process. From a purely definitional point of view, though, some agile frameworks like Scrum do have firm deadlines (primarily at iteration boundaries), while others like Kanban do not.

  • 1
    In a real commercial environment I think deadlines are unavoidable, many businesses set them as part of their wider marketing strategy, hence why I wrote that the scope should be variable and realistic based on the time we have on the project.
    – bobo2000
    Commented Jan 17, 2018 at 22:45
  • @bobo2000 Maybe I was led astray by your question title. In Scrum, scope is supposed to be the elastic element at the Sprint level. It’s arguably schedule that’s the flex element at the release planning level. However, I don’t think you can generalize that to all agile methodologies, which is why I’m suggesting that “deadline” be used very judiciously.
    – Todd A. Jacobs
    Commented Jan 18, 2018 at 2:43
  • 2
    @bobo2000 I want to support Todd's answer with my experience as well. The need that deadlines address (meeting market needs in a timely manner) is likely unavoidable. I've seen many teams move to more sophisticated solutions to that problem than deadlines.
    – Daniel
    Commented Jan 18, 2018 at 16:52
  • 1
    I'm using the term "sadline" which I've explained further down, but I like the way you've explained the difference between the two types.
    – Lunivore
    Commented Jan 20, 2018 at 18:54

Sure. Deadlines are simply one type of finish line. With agile software development there are many possible finish lines: scope, time, money, value, etc.


  • Can you expand on this? As currently written, this is more a comment than a canonical answer that’s useful for future visitors.
    – Todd A. Jacobs
    Commented Jan 19, 2018 at 17:37
  • I like the brevity which answers the questions. Welcome to PM.SE! Commented Jan 20, 2018 at 17:56

Todd Jacobs wrote an excellent answer, but I feel he missed an important type of Agile project where deadlines definitely exist. The ones where there is a deadline, but the scope is variable.

This is common on research projects that are being drip funded. For example, I joined a team at the beginning of November. We had exactly two months to accomplish as much as we could. At the end of that time, our progress was evaluated. If it looked like the project would be feasible, we would be extended for another few months. If the team, and the check writers, felt it was worth while to continue, we would.

We were extended another 3 months and will repeat the evaluation at the end of March.

Basically, the idea is to set a fixed budget and accomplish as much as possible with that budget. When the budget is gone, the project is done. (Unless someone decides it’s worthwhile to allocate more budget.)


No, not necessarily. The scope is fixed for almost all of the software development projects. Only in certain cases it might change due to regulatory requirements. Otherwise it is fixed.

Please note, not capturing the relevant user story during the session (thinking it can be done later) is a different issue altogether.

For the industrial and research and development related projects, the scope can be variable.

Irrespective, the schedule deadline is either 30 days or two weeks known as Sprint cycle. This means, decomposing into units and working towards the deadline is the key.

  • Down-voting is good and healthy. While reasoning will help me to understand and learn will help a lot.
    – Devasuran
    Commented Jan 19, 2018 at 4:38
  • 2
    Didn't down vote; here's some feedback. A common, manufacturing-based definition of a project requires fixed scope and why software projects often fail. Scope is entirely flexible when working with the agile software development philosophy. A Sprint can be any length no more than one month (even 4 or 27 days). Successful modern software development mind sets promote value over deadlines and fixed scope via a product solution mentality over a project schedule march. HTH Commented Jan 19, 2018 at 15:38
  • Scope isn’t inherently fixed in all methodologies. Even when I practiced waterfall, scope often changed over the SDLC through underlying implementation changes or formal change control. But I agree that many people think of software applications development as having fixed scope; that’s a big part of what the agile manifesto is trying to draw attention to regarding the mindset.
    – Todd A. Jacobs
    Commented Jan 19, 2018 at 17:36
  • I downvoted. Here’s why: 1) I’ve personally worked on teams with 2 week sprints, 1 week iterations, and no time boxes at all. If I thought a 3 or 4 wk timebox made sense in a situation, I’d happily try that too. 2) I’ve never seen a fixed scope project. I’ve seen projects that were claimed to be designed up front and fixed scope, but in reality scope always slips due to the reality of time & budget. There’s just simply a lot wrong with your answer.
    – RubberDuck
    Commented Jan 20, 2018 at 19:36
  • @RubberDuck - please excuse the delay. Thank you for replying. For me this is an opportunity to learn. Please bear with me if I sound imbecile. 1) When you say you have worked for 2 week sprints - to me it means it is time-boxed [schedule here], and you should be knowing what goes into the sprint [scope here]. Both are fixed. Any changes shall be considered later but not during your release. is my understanding wrong here?
    – Devasuran
    Commented Feb 6, 2018 at 5:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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