(If you’re in Seattle, I teach a monthly introductory class on Agile project management that covers this topic of Scope Creep. You can see the latest upcoming class schedule here: https://generalassemb.ly/instructors/paul-gambill/6046)
Scope Creep
What is it? Why is it a source of frustration? How should projects deal with it?
Scope creep. It just sounds dirty. Why is it such a widely reviled thing in projects, especially software?
In a true waterfall project, increasing scope, or adding new features or items to an existing project plan, can be a really bad thing. The project has been planned with specific budget, schedule, and resourcing in mind that is directly tied to the scope of the work to be done. Planning and predicting in that way can make a lot of sense when the work effort is predictable.
But software is inherently an unpredictable thing. Google search for “how to estimate projects”, and you get 70 million hits. Add the word “software” to that search, and you find 35 million. 50%. Clearly, estimating software work to a scope is a difficult subject, and there are far too many people (read: everyone) who struggle with this.
Example: Your software project has been estimated by the management at 6 weeks to deliver features A, B, C, and D. Two weeks in, your key stakeholder sees the product with features A and B complete, and is inspired with an idea for a new feature: E. Boom, scope creep.
This is an unavoidable circumstance. Software project stakeholders will always ask for more. Sometimes they respond well to pushback from the project team, and sometimes they don’t.
So what is this fictional team to do? If you’re a member of that team, would you be upset about this new request?
When faced with hard questions like this, I always turn to the large Agile Manifesto banner hanging on our wall for value guidance:
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
Working software. That is what matters at the end of the project. Success of a project should be measured by asking the question, “Are the stakeholders and customers pleased with the result?”
When feature E came along, the response should have been a request to stakeholders to order the backlog and determine which feature would deliver the most value. If that means feature E is now higher in the backlog than feature D, then that’s the new project scope.
The 6-week project scope didn’t creep, it just became a new scope for what is at that point a 4-week project.
Changes are opportunities for making the project even better than it could have possibly been. Change is good. Adapting to change is even better. Those changes will happen whether you adapt or not, and everyone will be better off accepting that.
My challenge to you, depending on your role:
- Development team: Be willing to accept feedback from stakeholders and incorporate that in your project. When the backlog changes, respond with your expert opinions on what the implications of the change are. Maybe that new feature request is far more difficult than it seems and can’t be done in the remaining time without modifying it. Or maybe that new feature affects how another planned feature should be implemented. But above all, remember that the final product with their request will likely make them even happier than without that request.
- Stakeholders: When you see something you want to change in the project, consider the effects of that request. You may have to prioritize something else lower in order to fit it in. You may need to rethink a large portion of the project because the request breaks an existing paradigm. Trust the opinions of your development team, and they will learn to trust your requests more.
- Management: Encourage the team as well as stakeholders to consider the project always in flux. Seek out opportunities for changes that will please the customer even more. Lead the team in honest and authentic feedback to stakeholders when they make requests, especially with respect to budget, schedule, and prioritization needs.
How do you physically feel when you hear or read the words “scope creep”? What would changing your perception of scope creep do for your team and for your customers? I’d love to hear feedback here or on Twitter: @paulgambill.
