PM Articles > Executive View > How Scope (control?) is handled (or not) in Agile

How Scope (control?) is handled (or not) in Agile

by Cinda Voegtli

Here are two related questions I received from a site member about Agile, my answer, and Kent's and sanity check on my answer.   These are great questions not just for a PM, but for an executive understanding of how it works and what they do and don't get to do in terms of driving scope and date changes when the team is trying to run by Agile principles and practices!

"How do you protect the scope of an Agile project, since Agile projects leave space for users to change their requirements ?"

Cinda: Agile projects leave space for users to change their requirements, BUT – not within short plan-develop-release iterations.  A key concept of Scrum, a specific approach to how project teams schedule and manage their work in an Agile manner, says that you prioritize features into iterations of two to four weeks…. And once the iteration has started, the scope cannot be changed (added to or the list changed) until the iteration is finished. Once it is, customers and team looks at results, any new information, changes in priorities etc. and decide what the next iteration is about.  So you protect the scope in an iteration to ensure the iteration can finish quickly (although lowest priority stuff in that iteration may not get done if the team runs out of time. In which case it is considered for the next iteration.)

Other than that, you do NOT protect the scope in the large (protect whatever got envisioned as the scope of the entire project way up front), because that’s the point of doing Agile – acknowledging that you can’t know everything up front, things may change during the project, you will definitely learn more about true customer requirements as you go.   You want to pair delivering high priority value to the customer at regular and frequent intervals, while allowing scope to adjust between interations based on learning more about what the customer really wanted etc etc. as you go along.

Kent's additions:  Yes to Cinda's answer plus a couple of nuances.    Teams using XP [extreme programming, another specific technique in the Agile family] may allow features to be added to an iteration, but the customer must pull a feature of equal or greater size out of the iteration in exchange.  Basically, you are keeping the overall amount of stuff that a team works on during an iteration the same.  I prefer the Scrum approach better because it allows for more focus (what if the team started working on the feature that was yanked as a result of adding a new one) and really, can't the business wait 2 - 4 weeks for a change given the much longer waits they are used to today?

Also, it's important to be clear about the level of requirements we are talking about.  The requirements assigned to an iteration or "sprint" in Agile are at the "things the system should do" level, allowing the more detailed requirements of things like UI design to be defined in the iteration, so it may still look like requirements are changing, but they aren't. They are just being better understood and defined as you quickly create things with tight customer feedback.   In most projects I have experienced, what people claimed was requirement change was really just refinements of implementation brought on by better understanding of the desired solution.

You protect the overall scope of the project by defining scope as what problem the system will solve as opposed to a particular list of features.  That is why it is so important to understand the purpose of the project.  It may turn out that far less functionality is required to appropriately satisfy the purpose of the project.  You also protect overall scope by ruthlessly prioritizing features.  Make sure that all the really important stuff is done first (with importance measured by how much it helps accomplish the purpose). This leads into the second question.

"How to do you protect the delivery date of an Agile project?"

Cinda:  The idea in Agile is to deliver working product to the customer more frequently than our past typical monolithic projects.  At the end of each relatively short iteration, the aspect created during that iteration works and can be delivered to customers. The end date of an iteration NEVER EVER is changed.   Having regular iterations that deliver working product off a prioritized list - instilling that discipline - is core to the beneficial "regular, frequent business value delivery" Agile is intended to bring. You show the customer what is ready and it can be delivered to them if they want it.

Kent:   And when you reach the overall delivery date of the agile project, you deliver.  You have been giving your customer regular updates on your progress, and now give them the appropriate information to decide whether to extend the final delivery date, but that should be the exception, not the norm.   That is why prioritization is so important.  Agile methods typically timebox features/functionality into iterations and hence treat time as fixed, allowing scope and budget to flex.

Not all comments are posted. Posted comments are subject to editing for clarity and length.

This is really timely information! My question is: how do you propose using Agile methods to a business that is firmly entrenched in the "due by date x" mentality (even though that hasn't proved to be successful)? At my organization the business leaders have been trained to expect a solid, project-complete delivery date - so I anticipate challenges in presenting this new methodology to them.

Brian, Kent McDonald is going to post some clarifications on this shortly. He's our internal Agile-experienced person; we've been one-two-punching this subject as I come in more as a newbie to formal Agile asking some of these same questions! Just wanted to give a heads up that you might see an answer from him rather than me.


Agile methods are actually perfectly suited for "due by date x" projects. Remember the timebox concept discussed in the post. Your iterations are a specific length that does not change, even if the team will not be able to deliver everything they commmitted at the beginning of the iteration. Just as the length of each duration is timeboxed, so to can the length of each release and the overall project can be timeboxed.

As mentioned in the post, agile methods fix time, and vary scope. When the appointed time comes to release, what we have built is what we will deliver. This of course places a large emphasis on making sure the team is delivering highest priority functionality first AND is delivering features that will produce a conceptually whole product that will actually add value.

A final word on due by date x projects - make sure everyone involves in the project understands why that particular date is selected. Hopefully it is driven by a definite business need and is not just some number pulled out of the air. If the project must have date is set because "that seems like a good time to be done", the project team will have more difficulty making rational decisions about what should stay or go when compared to a date set by a definitive business event. Due dates are good, as long as they are not completely arbitrary.

I come from a development background and work with many R&D teams. The agile framework works best applied by teams that stay in existence over a long period of time and continually evolve a solution. But the agile framework can be applied to IT projects with beginning and end dates. It works well for projects with nebulous scope or poor business understanding.

I don't think the end date is ever better than the estimate that would have been determined by waterfall methods. However, the benefit gained, when its appropriate to do so, is the frequent release of functionality to the end user/customer.

This requires eduction and buy-in from the customer, but can be handled by customer proxies and a product manager role.

'Backlog maintainance' (managing the priortized list of work to be done) happens all the time, especially at sprint and release boundaries. The process stretches the requirements elicitation phase over a longer time period, concentrating as Ken has said, on the highest value features first.

Project management can still do their normal estimating for the high level features over the full time frame of the project. That's related to and needed for roadmapping and coordination with marketing. The key difference is that these features are treated as Epics --very high level user stories. The affected development teams or product managers/product owners break these into sub-features and stories, model the dependencies between the stories and then prioritize the stories into sprints. For complex projects with multiple teams, this means planning releases many sprints in advance. Of course, after every sprint, the overall priority of the epics is revisited and each sprint is planned based on today's knowledge and today's priorities.

Agile never means less planning. I find it means more planning, but planning at the right abstraction layer. Details are defined as the development team needs the details.

If the consumer value proposition for the product is well defined and the main features are prioritized, the development focuses on the work in front of them today. For the 2-4 week sprint (and 4 weeks is way too long), outside details are effectively ignored and the plan is followed, producing consumer ready, fully tested code (possibly only for limited trial use as the feature set will be very limited initially). Then everyone picks up their heads and takes in reality and re-plans the next iteration.

Big changes have to happen to learn the skills required to make database changes. migrate data between iterations and evolve design over time. This is not just project management. The R&D team (designers, architects and testers as well as developers) have to learn to work in this incremental way. Continuous integration, automated testing is needed right from the start.

Customers/users get functionality frequently and become part of the overall concept and design of the system, if they choose. That feedback is a necessary part of the process. As this happens, the business practices continue with whatever knowledge managers can garner from the development progress.

Scoping factors such as relative size and storypoints can be assigned to Epics and team velocity can be applied to provide estimates for how long they will take.

Estimation based on storypoints is another skill that improves over time but specific values are very team-specific.

There is a need for management to realize the value provided by an agile organization, with layers of decision making occurring on boundaries and at the appropriate abstraction layer, but until this happens, project management can provide a wrapper around the development team and put an almost business-as-usual status shell around an agile team.

Just don't interfere by injecting priority changes outside sprint boundaries.

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.