Project Management

Project Management Central

Please login or join to subscribe to this thread

Topics: Agile
Agile Project management - what is the allowable percentage of requirement change and scope change in a agile project.
Dear All,

I am currently preparing for an PMP, I would like to know what is the allowable percentage of requirement change or adding new requirement or change scope from agile project perceptive.

Can we consider detailed scope as a product backlog in a agile term.

Regards,
Ma
Sort By:
You can attempt to forecast the amount of change but what is actually done ought to be decided by the costs versus the value of each change. I don't know of any fixed formula to forecast the amount of change because that must be highly dependent on the type of work and the environment. Very different constraints and assumptions must apply in the case of building construction compared to software development for example.

An agile team ought to be continuously refining the scope and detailed definition of what they work on. I wouldn't make detailed analysis a product backlog item because it should be implicit for every item on the backlog. Product backlogs generally outline the high level of what is to be delivered with the expectation that the team then need to identify and refine further details and add new things to the backlog as required.
There is no allowable percentage of change unless your internal governance processes define some kind of limits.

I don't even know how you would quantify that. Requirements management can be a very involved process. The list grows from high level customer and other requirements like regulatory, to a detailed set of product requirements, and those often change as the solution is better understood.

Detailed scope is absolutely part of the product backlog. You don't know the details of the solution from the outset, therefor you don't know all the problems you need to go solve to make it work. As you learn more and ask more detailed questions, the scope evolves.

As someone studying for the PMP, you need to consider agile as a set of guiding principles, not a rigid structure. If you see a question that asks for defined limitations on what is allowable, then what they are probably testing is whether you understand that "agile" is not a set of rules.
...
1 reply by Manigandan devarajan
Oct 16, 2022 1:45 PM
Manigandan devarajan
...
Hi Keith ,
Thanks for your explanations,
I would like to add one more question, when you say that the project is always based on the cost we spend and return on investments

As per your statement if there are no percentage level of changes defined in the agile. who do you measure the capital expenditure and measure the financial benefits of the project(ROI)

Thanks
Ma
Oct 16, 2022 12:51 PM
Replying to Keith Novak
...
There is no allowable percentage of change unless your internal governance processes define some kind of limits.

I don't even know how you would quantify that. Requirements management can be a very involved process. The list grows from high level customer and other requirements like regulatory, to a detailed set of product requirements, and those often change as the solution is better understood.

Detailed scope is absolutely part of the product backlog. You don't know the details of the solution from the outset, therefor you don't know all the problems you need to go solve to make it work. As you learn more and ask more detailed questions, the scope evolves.

As someone studying for the PMP, you need to consider agile as a set of guiding principles, not a rigid structure. If you see a question that asks for defined limitations on what is allowable, then what they are probably testing is whether you understand that "agile" is not a set of rules.
Hi Keith ,
Thanks for your explanations,
I would like to add one more question, when you say that the project is always based on the cost we spend and return on investments

As per your statement if there are no percentage level of changes defined in the agile. who do you measure the capital expenditure and measure the financial benefits of the project(ROI)

Thanks
Ma
...
1 reply by Keith Novak
Oct 17, 2022 12:09 PM
Keith Novak
...
Project benefits are not always quantifiable in purely monetary value. Some strategic investment projects may have a negative ROI or NPV in directly measurable tersm but have other values like developing your team, improving your internal processes, or gaining entry into new markets.

When projects are evaluated based on cash flow measures, how that is done can vary. Iterative projects might start out with an estimate of the total value achievable by a project. As you add features you capture some value, but the residual value declines and you may decide whether there is justification to do more, or spend your money where you can get more payback.

How you measure the cost and benefits also varies widely due to the nature of different domains. In banking for example, you will have different cost factors for financial engineering where portfolios are all on paper, compared to investments in brick-and-mortar projects. Understanding the mechanics of different cash flows is then necessary to develop different cost models that fit your unique situation.
The same than any other approach. Some people has misunderstanding "embrace the change" like "you can make changes when you want" and that is the first step to fail. Change management is embedded into all the agile based methods or frameworks.
I agree with Keith - There is no allowable percentage or one-size-fits-all for changes. In Agile, change is welcomed in this adaptive environment and it differs from one project to another based on so many factors.
Manigandan -

You've got some good feedback from others so far. The one thing I'd add is don't think of the backlog as equivalent to a detailed WBS. The latter represents 100% of what is "in scope" for your project whereas the former is not. Remember that just because something is in the product backlog doesn't guarantee it will be delivered. While the backlog should never be treated as a pure wishlist, shifts in customer needs, constrained budgets or timeframes might result in certain PBIs not being delivered by the time the project ends, and that is totally fine.

Kiron
Oct 16, 2022 1:45 PM
Replying to Manigandan devarajan
...
Hi Keith ,
Thanks for your explanations,
I would like to add one more question, when you say that the project is always based on the cost we spend and return on investments

As per your statement if there are no percentage level of changes defined in the agile. who do you measure the capital expenditure and measure the financial benefits of the project(ROI)

Thanks
Ma
Project benefits are not always quantifiable in purely monetary value. Some strategic investment projects may have a negative ROI or NPV in directly measurable tersm but have other values like developing your team, improving your internal processes, or gaining entry into new markets.

When projects are evaluated based on cash flow measures, how that is done can vary. Iterative projects might start out with an estimate of the total value achievable by a project. As you add features you capture some value, but the residual value declines and you may decide whether there is justification to do more, or spend your money where you can get more payback.

How you measure the cost and benefits also varies widely due to the nature of different domains. In banking for example, you will have different cost factors for financial engineering where portfolios are all on paper, compared to investments in brick-and-mortar projects. Understanding the mechanics of different cash flows is then necessary to develop different cost models that fit your unique situation.
I would suggest that the "allowable change" should be defined in the initial business case or project concept. Projects, or tasks within projects, with tightly defined objectives (cost, time, scope/quality) would have narrowly defined change tolerances whereas loosely defined projects or tasks are prone to significant changes.

I guess what I'm saying (as are most others) is that the project maturity and environment dictate the 'rules' regardless of the delivery methodology.
In Agile, there is no such thing. Agile philosophy welcomes change in fact, even late in development. Agile processes harness change for the customer's competitive advantage.

Values of Agile philosophy.

Individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; and. responding to change over following a plan.
I have not come across a limitation, but I have seen assumptions of the amount of expected changes to a well defined scope, based on previous similar projects. Ranging from 10% of scope up ...
Those were used in estimation and risk contingencies.

In one particular project, with a 2 digit million budget, the scope was defined on 11 pages (not well defined) which translated into 600 pages of a requirements document after 1 year. No changes (zero) were identified in this, and I asked for an external audit of that, because it tripled the budget although it was a fixed price. Implementation and test also did not bring up changes, in additional 2 years.
BTW, I survived this.

And another factor: project duration. Shorter projects will experience lesser changes, just because the pressure is felt by anyone, and new ideas cannot grow fast enough.

Please login or join to reply

Content ID:
ADVERTISEMENTS

"How much deeper would the ocean be if sponges didn't live there?"

- Steven Wright

ADVERTISEMENT

Sponsors