Much has been written and talked about regarding the Iron Triangle in the software development community. For those of you unfamiliar with the concept, there are three “constraints” to any software development project — Scope, Schedule, and Resources. Oh, and consider Quality as a non-move able object (which can be discussed in some other context later).

Resources include money and budgetary stuff. While I usually say that people are NOT resources, in the end this is where people “fit” in this example.

Schedule is the time you have to deliver on a project.

Scope includes the features and functionality of the deliverables you will be providing to the end user.

Scott Ambler has written about how this triangle is really “broken” today, and you can read more about it here. There is some good information there and much can be learned from it.

Today I will focus on what is considered the only movable line within Scrum, and that is Scope. Why?

From a Resource perspective, each Sprint normally has a fixed amount of people and equipment. You can easily predict the burn rate for a Sprint.

From a Time perspective, each Sprint is normally a fixed length of time (anywhere from a week to a month, depending on the team norms).

So, that leaves Scope as the one item open for discussion during a Sprint. Let me explain further…

The Product Backlog contains all of the features and functions that the Product Owner has identified (with the team) as the highest priority items to deliver for the overall project. Following each Sprint Review and Retrospective, the team gets together during the Sprint Planning Meeting to discuss the latest Product Backlog and decides what items should be pulled into the next Sprint.

Once the team — along with the Product Owner — decides what to pull into a Sprint Backlog, the Product Backlog then becomes part of the background noise in a project. Once a Sprint gets started, the team focuses on the Sprint Backlog while the Product Owner — and other outside stake holders (Chickens) — can play with the Product Backlog to their hearts content. Outside the team room. Responsibly (remember that… do not do things blindly or irresponsibly!).

So, the team gets started with their Sprint and is chugging along.

The Scope is fixed. The Resources are fixed. The Time is fixed — and ticking away. All is well until about mid-way into the Sprint when….

“Uh-Oh Mike… I see from the Burn Down Chart that we are not gonna make it!”

What should the team do?

Panic?

Uh. No.

This is actually something that is normal (and, by the way, CAN happen in reverse (as in… “Mike, we have some bandwidth…”).

And either way… this is actually a healthy thing if you work it the right way.

The WRONG way is for Chickens to come parachuting in (because that is what they love doing) and offering to “help” by adding what….

RESOURCES or trying to EXTEND the Sprint TIME.

Remember… on Resources… nobody can make a baby in a month by adding eight more women. Really. And time… well… that is fixed; as much as we want more hours in the day.We will end the Sprint when we will end the Sprint. And be done.

So… that leaves the Scope. Here is what should occur….

The team should sit down and have a facilitated discussion with the Product Owner about what is happening (this should not be a surprise for an active Product Owner) and why the Scope needs to be adjusted.
If the Product Owner is truly empowered by the outside stakeholders to make a decision, the Product Owner can then take user stories and tasks OUT OF SCOPE for the Sprint and add it back to the Product Backlog to be re-prioritized for a future Sprint.

Is this hard?

Sometimes.

OK. Most of the time.

Is this reality?

Yes. And that is why Scrum is set up to deliver working software at regular time intervals using fixed Resources and Time throughout a Sprint.

Should you follow this advice blindly?

No.

Be responsible. Think. Really.

Gotta run…

Please send comments, questions, criticisms, ideas, or whatever here.

You can also enter The Forum to discuss this cartoon and other Scrum topics. Thank you!