Is it valid and possible to cope fixed unmovable deadlines into Scrum?

I guess it is just confusing to me because I thought one of the core principles of Project Management is to help identify realistic estimates of a completion date based on limited information. Is there a branch of Project Management, specifically Agile or Scrum Project Management that concerns the opposite, starting at the completion date and working backwards to figure creative ways to fit everything in?


I am trying to understand the methodology and strategy of project management in my current company. It is a large financial institution and there are hundreds of projects ongoing at any given time. There is a large Program Management office that is collecting status information on many different ongoing work threads for communication of status up to executive level. The Project Managers maintain project plans and coordinate project status information from project resources to the Program Managers.

The odd thing I can't figure out is that when a project is in conception, there is no real technical effort to determine estimates of effort or time on the project milestones. At this phase it seems to be completely unimportant, because every project deadline are set by IT executives or by the LOB, sight unseen.

After we are told what the date will be we are then told to do formal estimation of effort (story points) rather than time because the organization has an executive mandate to be Agile and Scrum. The weird thing is that after we identify all of the Epics and T-Shirt size everything, the Project Manager is still required to figure out how to fit all of this into the pre-determined deadline. To do this we split and do a detailed story point estimation of a single Epic, usually a Small size, then the total story points of that are used comparatively to figure out total assumed story points. From there the Project Manager determines velocity and proves whether all of the project milestones are achievable by the deadline.

The concept of Minimum Viable Product is non existant. The PM has to show how many people are needed for this deadline to be possible and if it is too expensive then the project might be cancelled before it even starts.

The thing is that for the past several years nearly every project could be considered a failure because they almost never hit these deadlines regardless. What I don't understand is that despite failure after failure, nothing substantial seems to change. It certainly doesn't seem that being late on the project really matters in the long run. When the project runs late then status meetings increase and general anxiety seems to increase, but just about everybody keeps working ahead as they typically do.

Other people who have been at the company for a long time have told me that their are actually two dates. The formal deadline that goes on paper, and the date that executives actually anticipate when the project will be done in reality. When I asked why not just make the deadline reality, they almost universally agree that executive leadership feels that when projects run late on paper then people "work harder".

I don't see this working for a number of reasons. Veterans at the company don't feel the pressure because they believe there is an attempt to manipulate them into working harder. Newer people get demoralized and stop trying. Everybody spends more time in status meetings with anxious program managers rather than focusing on project work, and finally the nature of the work is more knowledge based and managing external dependencies than hard core work with rows of people furiously typing at keyboards until 2am. Most everybody works a solid 40 and goes home regardless of pressure because often staying late wont get real roadblocks done any sooner.

  • 2
    Scrum has fixed deadlines and variable scope. Thus, it fits if you can accept variable scope. If you have fixed time and scope, no methodology will save you.
    – Sklivvz
    Jul 2, 2015 at 16:25

4 Answers 4


Agile/Scrum process can be used for projects with fixed unmovable deadlines

Is it valid and possible to cope fixed unmovable deadlines into Scrum?

Yes. We did a project related to the Olympics using Scrum. Naturally, the deadline is fixed unmovable. There is nothing wrong with this. We were able to adjust scope so that we fit in what could be accomplished to launch in time for the opening ceremony. In your case, your project managers also seem to have flexibility in getting resources to match. You can see Mike Cohn's presentation about applying Agile to "fixed-date, fixed-scope, and fixed-everything projects".

we are then told to do formal estimation of effort (story points) rather than time because the organization has an executive mandate to be Agile and Scrum

Doing the estimation in story points is the right approach. If you need a good reference, read Jeff Sutherland's Story Points: Why are they better than hours?

we split and do a detailed story point estimation of a single Epic, usually a Small size, then the total story points of that are used comparatively to figure out total assumed story points.

This is not unusual at that stage in the project. As the project progresses everyone (development team and Product Owner) will learn more about the project. And the Product Owner can make adjustments to the priority accordingly.

The PM has to show how many people are needed for this deadline to be possible and if it is too expensive then the project might be cancelled before it even starts.

This is the right business approach. If the Return on Investment (ROI) is not there, why do the project?

From there the Project Manager determines velocity

If the Project Manager is assessing velocity empirically (based on actual velocity achieved by the team in 3 sprints or more) then that is OK. Otherwise, it could be way off.

Beyond that, you got digressed into much speculation, without covering essential information that can help us understand your process better:

  1. How and who determines scope? Do you have a Product Owner who does that? or do you work with a requirements document?
  2. Does your Product Owner share with the development team the vision of the product and the business goals to be accomplished?
  3. Do you demo working code at the end of each sprint to the stakeholders? And get feedback?
  4. Does the development team remain relatively stable? Or do you form a team for each project and then disband?
  • The answers to all of your questions are yes, but the product owner at least in our specific project needs like 98% of the entire project milestones or it is completely valueless to the business. The nature of the project is such that this actually makes sense. Scope and time are fixed and while there is a huge budget it seems like on paper they want to paint a rosier picture to keep things going Jul 1, 2015 at 21:33

Agile does support to concept of fixed deadlines. You prioritise your backlog and get as far down the list as you can by the time the deadline has been reached.

What you can't do is fix both the time and the scope.

You can, in theory, vary resources and keep time and scope fixed. However that ignores the difficulty of ramping up resources. As Brooks' law famously states: "adding manpower to a late software project makes it later". So, to fix time and scope and just vary resources you would need to be able to predict well in advance any potential delays.

You could also argue that time and scope can be fixed if you throw a huge amount of resource at the project. But even that can fail, as output can potentially decrease as the number of people on the project increases and communication becomes a problem (the n+1 problem).

The idea of setting deadlines to make people 'work harder' has been largely disproved in information based industries. The problem is that there are many different ways of solving any coding problem and the quickest solutions are frequently the worst in terms of quality and future expansibility.

Perhaps your best approach in this organisation would be to propose they run a small trial project following agile principles rather than their current approach. Agree on some metrics that will measure the success of the project before it starts. Sometimes it just takes a demonstration of success to win them around.

  • This would be problematic to approach them with such a suggestion as the suggestion itself implies at a fundamental level that they are currently not following Agile principles. It is quite a hot button political issue that our IT leadership insists on our organization somehow being "Agile" even with no real understanding or concern about this mission from LOB. Merely to suggest publicly that we are doing it "wrong" can make you a lot of enemies. I have no will to stick my neck out in this way and frankly don't care to improve the company. I am just trying to understand how they operate. Jul 1, 2015 at 19:34
  • 1
    It sounds like a challenging place to work. One other option would be to bring in an external agile coach. Sometimes there is more willingness to listen to an outsider (particularly if they are backed up by a strong reputation). Jul 1, 2015 at 20:24
  • you would think that is challenging but again only if you are emotionally vested in the success of a project. If you are smart and put in heroic efforts then they reward you with nice bonuses regardless of project outcomes. It's only a bad place if you try to improve processes Jul 1, 2015 at 20:29
  • I fall back on old school PMI Order of Magnitude estimating. "The date is fixed. Right now, six months out we have 50% confidence in the scope. In a month it will be 60%, in two months 80% and in three, we'll have a 95% confidence of the features that will ship on the required date." This isn't new to agile, this is business leaders having the classic "want my cake and eat it to." You just have to communicate clearly. Jul 1, 2015 at 22:02

Adding to this, I highly recommend tracking amounts and sources of "emergent work" (whatever was not in the initial backlog vs. velocity calculation) as you go, and continually factoring this into your planning, or predicted scope. By this I mean points for "unknown unknowns" or new backlog items that come up every sprint, points for feedback, points for pivots due to user testing, points for standard "oops that was bigger than we thought". In my experience, this is by far the biggest single area that is overlooked and puts teams in a bad position with management when it comes time to hit their original scope estimation. Many agilists will say if you measure velocity with these things happening, it will simply "come out in the wash", but that isn't actionable (for instance addressing excessive or increasing feedback or pivoting) and it doesn't provide enough transparency overall.


You are not alone. Many companies call themselves agile but only few really are. What sounds weird is that your company requires universal story points that apply to everybody. Story points are a relevant metric useful when a team has some history and knows their velocity. Otherwise story points are just random numbers. I worked for company similar to yours and I tried to educate them about SCRUM. After couple of months of frustration I gave up and quit. Sometimes corporate or "we have always done so" mindset is unchangeable.

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.