Did I get it right that Scrum team is never subject to project time pressure (no demanding to complete tasks within estimates, no deadlines, etc)? I mean external pressure (such as from the customer or manager in PMBoK).

The Scrum guide says that a team doesn't make estimates and doesn't commit to these estimates - the team only makes their forecasts and tries to follow them. There is no source for possible pressure (from the Scrum guide's point of view), right?

I'm NOT trying to criticize Scrum - this is just a simple question about this methodology.

  • 3
    Scrum says nothing about sources of possible pressure, but one of the Agile principles says "Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely". That's a statement that implies that you shouldn't have too much pressure as all things fail under too much pressure, including Scrum teams. Everything else (including how much pressure) is left to those implementing the Agile principles.
    – Bogdan
    Sep 29, 2020 at 15:19

7 Answers 7


Work and pressure is a spectrum

If you do something like Waterfall it doesn't mean that you work at full capacity, and if you do something like Scrum it doesn't mean the team can slack off. If you do Waterfall it doesn't mean you are under pressure to do the work, but if you do Scrum you can just relax and do things when you eventually feel like it. These things have nothing to do with Waterfall or Scrum, they are related to how things work in a particular team, project, department, organization, domain, etc.

These things are a spectrum: from subjecting your people to a death march with unreasonable deadlines and larger than capacity amounts of work, to people just chilling in the office while watching movies online. Again, these have nothing to do with Scrum or whatever methodology you use. It depends on the project, company, management, clients, etc.

Throughout history, in various context, people have figured out that you can't put infinite pressure on teams to make them do what you want in the shortest amount of time, because people burn out, start making mistakes, introduce defects into what they are doing, etc. Agile simply recognizes this and brings more attention to it than more traditional project management approaches that don't shy away from starting death marches. It's referred to as sustainable pace, a work pace that the team should be able to sustain indefinitely. To give you an example, if you want to run a long distance, what approach do you think will work best? Start running as fast as you can, using all your strength and energy, or running "at a slower pace" trying to conserve your energy and strength?

Commitment vs forecast

The 2011 version of the Scrum Guide saw a change in the terms used for the work to be delivered in the sprint: Commitment vs. Forecast: A Subtle But Important Change to Scrum. Why? Because upper management were putting pressure on teams to finish everything in the sprint, something that, sometimes, can't be possible for reasons independent of the team. To put it bluntly, some were transforming sprints into mini death marches. From the same source:

In Scrum, the Development Team is now asked to forecast the specific work that can be done in a Sprint, rather than “commit” to it. This allows teams to focus on the things that matter in professional software development like quality, value, and continuous improvement, rather than satisfying an arbitrary obligation.

Business-facing people (Product Owner, stakeholders, customer…) must recognize the inherent uncertainty in building software of any real value and complexity. Their responsibility is to create an environment where Development Teams can succeed, and trust in those teams’ professionalism to do all they can to deliver things of value.

Inspect and adapt

But how do you know if the team's pace is a decent one, too fast, or too slow? Inspect and adapt. Are people interacting and collaborating in the office or are they sitting in isolation? You can watch videos on youtube in isolation, but team members can't work in isolation. Are there many bugs? Maybe the team is going too fast. Basic features take a long time to be built and you project isn't where you would expect it to be and progress seems slow? Maybe the team isn't going fast enough.

You inspect to see what's going on then turn some nubs to fix it. This can mean a lot of things, not just putting some more pressure on the team, or taking some pressure off.

Scrum values

When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone. The Scrum Team members learn and explore those values as they work with the Scrum events, roles and artifacts.

Successful use of Scrum depends on people becoming more proficient in living these five values. People personally commit to achieving the goals of the Scrum Team. The Scrum Team members have courage to do the right thing and work on tough problems. Everyone focuses on the work of the Sprint and the goals of the Scrum Team. The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work. Scrum Team members respect each other to be capable, independent people.

In simple words, you need the right people. No lazy developers slacking their butts off, and no crazy managers trying to impose death marches. Everyone needs to act professional and when they do, and collaborate to reach the same goals, the right balance of work and pressure will be reached. Of course, it goes without saying that there is a disclaimer: you can have dysfunctional organizations, dysfunctional projects, dysfunctional managers, and dysfunctional Scrum teams, to throw that balance out of whack in one direction or the other.


Everyone has deadlines to meet. Scrum helps teams to meet deadlines by making sure they align themselves to priorities set by a Product Owner and by working in short iterations. The expectation is that iterations are short enough that teams can have the best chance of meeting the dates they forecast for each set of deliverables. Scrum doesn't of course stop people making demands and applying pressure, it just provides a constructive way for teams to deal with such demands.


I think the key difference between Agile/ Scrum and the traditional waterfall way is: Time is "Fixed". It means Scrum teams work at a sustainable pace to deliver the highest priorities first. So, we minimize the situation when the team rushing time to deliver a "fixed" scope.

But it doesn't mean Scrum teams have no sense of urgency. They are value-oriented,

courage to do the right thing, and work on tough problems, commit to achieving the goals of the Scrum Team.

PM Reverse Triangle


Timeboxing. Time is always a limited resource, thus it should be rationally utilized. Development management process, using Scrum methodology, includes sprints, daily meetings, meetings on sprint planning, and etc. quateslab

The question is a false dichotomy. Scrum recognizes deadlines (see the quoted core scrum principle). Scrum rejects deadlines and urgency that are based on fictitious predictive WBS that are in turn based on temporal, ephemeral understandings of complex, dynamic requirements.

Scrum should be critically examined based on data and performance, not based on calumnies.

For the record, I'm not a fan of scrum; I don't like scrum, I think scrum is the new silver paste that management demands be applied to all bullets to solve all problems. But even I recognize that it is unfair to criticize scrum for offenses of which scrum is pointedly not guilty


Scrum is a framework. It doesn't specify all aspects of how to do work.

There is nothing in the Scrum Guide that specifies this one way or the other (aside from the timebox of the Sprint itself, but that has no direct connection to any project).

So, to answer your question as-is, the answer is 'it can be either way. It has nothing to do with Scrum whatsoever'.

The question of whether or not it's a good idea to have a Team be under time pressure is a separate question entirely. One which I've addressed here.

  • But the Scrum guide says that a team doesn't make estimates and doesn't commit to these estimates - the team only makes their forecasts and tries to follow them. What is a source of possible pressure then?
    – Daniel
    Sep 29, 2020 at 14:56
  • @Daniel See pm.stackexchange.com/a/20322/25606
    – Sarov
    Sep 29, 2020 at 16:04
  • @Daniel From the Scrum Guide: "The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate."
    – nvogel
    Sep 29, 2020 at 18:12
  • @nvogel "The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate." this means that estimations are made by the development team (not by the Product Owner or Scrum Master or whoever esle). This doesn't mean that the team must commit to these estimates.
    – Daniel
    Sep 30, 2020 at 9:15
  • @Daniel, Commitment is essentially a team/culture issue. If your team is suitably motivated and engaged then they will put in the effort needed to deliver. If they don't have the necessary commitment then no framework, Scrum or anything else, is going to solve that problem for you.
    – nvogel
    Sep 30, 2020 at 9:29

Disciplines like Scrum can help avoid "time pressure" because, unless there is an actual contractual obligation, "time" pressure is usually just "pressure." And that begins to show up when people start losing confidence that the work is actually making steady forward progress.

It is very important that your teams plan out their work accurately before they do it, that they spread the work out among all team members, and that they can, in fact, manage to do this. (Be sure there isn't a "lone wolf.") Also be sure that they are regularly and continually testing the system – both to ensure that the work is "really done," and to detect "regression" as soon as it occurs. Keep a close eye on the estimates vs. the actual rates of completion.


Scrum teams do face project time pressure. It is the way in which they handle that pressure that highlights the difference to traditional development.

For example, a Scrum team may look to flex on scope to achieve a deadline. They may also discuss changes to their ways of working, but only in the context of a full understanding of the implications.

A conversation might go something like this:

Product Owner: "The Christmas deadline is looming, how are we doing?"

Team: "The changes we made based on stakeholder feedback and the discovery of new work has put us back a bit. We could potentially look to cut out some of the low priority features? Alternatively we could look to reduce cross-browser testing, but that would have clear quality implications that would need to be explained to the stakeholders and agreed on."

The point being that the Scrum team does not ignore the needs of the business. However they deal with them in a transparent, realistic and collaborative fashion.

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.