.st0{fill:#FFFFFF;}

How Can Agile Work With Everchanging Scope? 

 March 2, 2022

By  Anthony Amos

Retrospectives are not bitching sessions. Or are they?

When dealing with ever-changing scope, due dates tied to features are nothing more than arbitrary guesses”

Tony Amos

You could benefit from some training and/or coaching before attempting to manage using an Agile process. Nothing in Agile makes a correlation between epics, a roadmap, and due dates. Epics describe the size and scope of an effort. A roadmap is a vision for the product. And Agile avoids due dates – especially dates far into the future. When dealing with ever-changing scope, due dates tied to features are nothing more than arbitrary guesses. That approach ignores the reality that no human can project when they will complete something that has not been defined. Due dates are vestiges of Waterfall, not Agile.

Agile does address projects with ever-changing scope and requirements. I’ll use Scrum as an example: Scrum fundamentally defines a Sprint as a period of time in which the team can deliver some working solution that has value to stakeholders. Many teams use a two-week Sprint, and some use three or four-week Sprints. The team decides on the Sprint duration based on what the stakeholders expect to be delivered AND sufficient requirements. However, the Sprint model’s success depends on a few ground rules; and the most important rule is that scope does not change once the Sprint starts. This is why Sprint durations are short.

The expectations of specific features being delivered by a certain (arbitrary) date become less important once the team is delivering in a regular Sprint cadence. Not many stakeholders will complain if they are getting working valuable features every 2-4 weeks. That is what being Agile is about.

I notice you say you are a Product Owner who is “in charge.” When you put it that way, I get the impression that you may be in a situation where Agile terms are being used, but the practices are not. If that is what is happening, then I hope you have access to a good Scrum Master to help you out until you can get trained.

Read more about managing Agile Teams here.

Anthony Amos


Anthony started creating software in 1981 when he curiously picked up the programming manual for a Wang OIS Word Processor while deployed with the US Navy. He had never seen a computer before, but he taught himself how to write programs that made his Navy work easier and more accurate.
After his honorable discharge in 1986, he began creating financial and analytical software for diverse organizations including Verizon Wireless, JP Morgan Asset Management, GoldenTree Asset Management, NASDAQ, Prudential Insurance, AT&T Capital Corporation, Lehman Brothers, Ernst & Young, and Blue Cross & Blue Shield of New Jersey.

Demonstrating his commitment to the principles and values of Agile Software Engineering, Anthony is a recognized SAFe® version 5 Program Consultant and holds many of the most challenging and difficult to attain Agile certifications. His practice is grounded in Agile Frameworks as he leads clients to implement Scrum, Kanban, Scrum with Kanban, Scaled Scrum with Nexus, and Scaled Agile Framework. He believes in using the framework that best fits the organization's cultural and business direction while maintaining disciplined processes.

Tony Amos

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Subscribe to our Agile newsletter