The Sprint as a project

The Scrum Guide states that “Each Sprint may be considered a short project”. We usually understand a project as a plan with a fixed time, budget and SCOPE.

If you take a look at the project management iron triangle, sometimes known as the triple constraints, one must make a tradeoff between the constraints. In other words all three sides of the triangle (scope, budget, date) cannot be fixed. Fixing all three sides doesn't work regardless of Scrum or Waterfall being used.

You can have fixed date and budget, but if you add scope one of those other variables has to change (push the date or add money to the budget to add more people). You can have fixed scope, but if you want to move the date up, you'll have to remove scope or add people. Adding people in a Sprint probably won't help in most cases.

Some show the triangle being flipped for Scrum, with scope being variable. In Scrum we fix the date (Sprint length) and fix the budget (number of people on the Scrum Team). We anticipate scope will change in complexity. We become comfortable with uncertainty. 

Hope this helps,

Scrum on.

I'm not sure where you found the definition of a project to include a fixed time, budget, and scope. The PMI uses this definition for a project:

A project is a temporary endeavor undertaken to create a unique product, service, or result.

Given this definition, it seems like a Sprint fits. It is a temporary endeavor, as it is timeboxed to no more than one month. A Sprint also produces at least one usable Product Increment, which is unique from all other previous product Increments.

It seems like a Sprint meets the full description of a project, as the PMI describes it in the 6th edition of A Guide to the Project Management Body of Knowledge. I haven't read the 7th edition yet to know how it compares or if they have changed the definition, but I would suspect they haven't moved it backward.

Professional Scrum Trainers as Ralph Jocham https://www.scrum.org/resources/project-vs-product-mindset explain the project mindset in the same way that I have described in the first post, guys. 

So if inside the scrum.org community we are talking about the project mindset as a plan with fixed time, fixed scope and fixed schedule, what is wrong? Our definition of a project mindset or considering the Sprint as a project? Nevertheless, leaving aside academic and conceptual discussions, is it helpful or useful to state that “Each Sprint may be considered a short project”?

I would rather accept the PMI's definition of a project. The PMI maintains and works with other organizations to maintain globally recognized standards related to project and program management. I'd say that thinking that a project is "a plan with fixed time, fixed scope, and fixed schedule" is wrong. If you leave that definition aside and accept the PMI's definition of a project, then it becomes correct to consider that "each Sprint may be considered a short project". Whether that is helpful or useful depends on your audience.

Thank you for your answers, Thomas and Chris.

Let me, anyway, try formulate the question in another way to inspect the utility of this debate:

Is it helpful to describe Scrum as a framework to manage complex problems and products (strategic level), but suggest, at the same time, that at the tactical level, the sprint-iteration works like if they were mini-projects? Doesn’t this definition create a lot of confusion? Does this definition bring a good representation of how Scrum actually works?

I'm not sure that I'd describe Scrum as a framework to manage complex problems and products. The thing that I'm not convinced of is that the product has to be complex. The environment in which the product is built or used has to be complex. In Cynefin terms, I'd consider agility in complicated and complex environments that are full of unknowns, both known unknowns and unknown unknowns. These unknowns, uncertainty, and ambiguity require the ability to adapt a plan as those unknowns become knowns.

I don't see any confusion with describing Scrum as a framework to develop products or services in a complicated or complex environment. I don't see any confusion with describing a Sprint as a project, assuming you are using a definition like the one from the PMI's PMBOK ("a temporary endeavor undertaken to create a unique product, service, or result") or ISO 12207 or ISO 15288 ("endeavor with defined start and finish criteria undertaken to create a product or service in accordance with specified resources and requirements"). I can see confusion if you describe a project as having a fixed schedule, scope, and budget since a Sprint doesn't have fixed scope.

So if inside the scrum.org community we are talking about the project mindset as a plan with fixed time, fixed scope and fixed schedule, what is wrong

In the Scrum.org community we talk a lot about complexity, and how we need an empirical approach rather than a predictive approach. Nothing is assumed to be true up front until validated. We encourage people to be comfortable with uncertainty, that mistakes will happen, and new ideas will emerge.

I agree a project mindset is more effective than the project mindset, and there are many pitfalls to running a project with Scrum. But that doesn't mean a team cannot run a project with Scrum. In the PSM I course we even mention you can think of every Sprint a project or that a cohesive set of PBIs turned into Increments over several Sprints could be thought of as a project.

The important point is that I don't think it was mentioned that all three constraints were fixed. In the traditional waterfall project he mentions, you fix the scope and then come up with the date and budget. 

Agile principles are different from Project Management guides. I could say that as a certified Advanced Scrum Master and PMP. 

I think you're considering these two terms as interrelated. However, they are from two different sources, and their context is not dependent on each other.

" A project as a plan with a fixed time, budget, and SCOPE. "

"Each Sprint may be considered a short project."

If you're building a bridge, it's too risky to change the material in the middle of the construction. A project with a fixed time, budget, and scope has a place for specific situations. In most cases, scope changes often; how to manage them is the question here.

In our organization, we keep release/projects time-boxed with minimal adjustments so that customers can get artifacts regularly. I can't say much about the budget because the project management team handles it. However, I do see an adjustment in the resources based on the priorities. Minimal, though, so it's safe to assume the budget doesn't fluctuate significantly. 

Next is the scope, where the agile approach plays the primary role. The goal of each sprint is to perform a set of tasks that brings a team closer to a release goal. Therefore, it's OK to make adjustments in the sprint backlog based on the finding by the team, such as taking a low priority bug out, adding something more critical, and so forth. However, if these changes are too often and chaotic, there is some issue with the refinement and planning meetings. It could also reflect an unclear release goal.

A few teams don't have a testable artifact after each sprint, so the definition of a sprint as a short project may not be applicable for all. Instead, for those teams, I see sprints as a means to achieve the release goal. 

Adjustments in sprint backlog and release backlog regularly could be an indicator of a good agile team. There is a sweet spot between changing backlog every day and an uncompromising commitment. Agile teams should strive to find that spot to accommodate the self-findings and feedback from the stakeholders.

Is it helpful to describe Scrum as a framework to manage complex problems and products (strategic level), but suggest, at the same time, that at the tactical level, the sprint-iteration works like if they were mini-projects? 

The Scrum Guide says "Each Sprint may be considered a short project". We could indeed think of Sprints that way...but if we do, there isn't a shred of evidence to suggest that they work like the "mini-projects" organizations often conceive them to be. For one thing, organizations often assume -- quite mistakenly -- that time, cost and scope all have to be fixed in a project, as you have indicated. Quality is then sacrificed on the altar. In Scrum, it's scope that would flex.

Each Sprint may indeed be considered a short project: a temporary endeavor that achieves a result of value. Strictly speaking, by definition it is one. But the term "project" is overloaded and already means something in companies.

It is not verboten to speak of projects in Scrum. We may think of Sprints that way. Yet the word might not always be helpful. I'd suggest it could be better just to speak of Sprints, products, and value.