All projects experience changing requirements and even though Agile projects embrace change as a way to ensure customer satisfaction, teams still need to minimize scope creep. Uncontrolled scope changes can create project delays, trigger drastic cost increases, cause frustration for team members, and lead to quality problems.
The following Agile best practices can help in avoiding these problems and keeping projects on track:
A constant focus on customer requirements
- Keep customers actively involved in the process by continually soliciting their feedback. Consider inviting them to daily stand-ups (as observers) so they are informed of the project’s current status and future plans, and are less likely to propose last-minute changes. If they understand the impact of scope changes and the tradeoffs needed to offset scope creep, they should make better choices when it comes to change requests.
- Verify the project scope with stakeholders during iteration reviews and subsequent iteration planning. Scope creep often results when stakeholders try to add features that they didn’t think of earlier in the project. Verifying scope at the end of each iteration allows customers to clarify their ideas and know that their requests will be addressed in the future.
An effective process for dealing with change requests
- Use the product backlog to prioritize new requests and prevent secondary problems. Funneling all change requests through the prioritization process ensures that they do not supersede higher priority items. It also prevents new requests from causing unexpected problems for the team.
- Channel all change requests to the product owner. The product owner’s job is to collect requirements and ensure that customer needs are considered for inclusion. Channeling scope changes through the product owner will ensure that requests are analyzed and incorporated without interrupting the current flow of the project.
Assurances to customers that their requests will be heard
- Explain to stakeholders that, when the process does not allow for immediate changes, they can be incorporated in subsequent iterations. Agile teams should remember: “don’t say ‘no,’ say ‘not yet'” when dealing with customers (an idea highlighted in “Managing Out of Control Requirements and Scope Creep” on GatherSpace.com). Assure customers that their suggestions are not being ignored; they will be discussed and prioritized before the next iteration begins.
- Use iterations and the product backlog to manage stakeholder expectations. Reiterate that iterations are short and set in timeboxes, and all requests are captured in the product backlog so none are lost.
An understanding that changing requirements may necessitate trade-offs
- Keep everyone informed. When new features are added, others may have to be removed or returned to the product backlog to make room. Discuss these trade-offs with the entire team so that everyone is aware of changes and can present new viewpoints that may uncover emerging risks. Effective trade-offs substitute requirements of higher value for ones with lower priority.
- Make sure any trade-offs fit within the plan. Requirements added to the work effort must be of roughly the same size as the requirements they replace. If there is a significant difference between the requirements (or if there is not enough time left in the timebox to incorporate the new request), it may not be possible to complete the work in time.
Very few projects are completed without the potential for scope creep; all projects experience requests for change in some form. Agile is efficient in its ability to adjust to change, but changes must be coordinated and controlled. Uncontrolled change may create customer satisfaction in the short term, but can create larger problems in the long run.
Mini case: Managing Scope in Agile Projects
Alex Murcheson hurries down the hall to catch up with Ben Hemmings.
“We’ve got a problem,” he said. “Ever since Ted Cranston became the new head of product development, he’s been in my office every 20 minutes. Now he’s insisting that we add two new features to the Glastonbury project.”
Hemmings frowned. “But we’re halfway through the last iteration before the launch!”
“I know,” Murcheson said. “But Cranston is adamant that they have to be in there. And of course, he doesn’t want to delay the launch—he wants to make a big splash with Glastonbury as the first completed project of the ‘Cranston era.'”
Murcheson has been a brand manager at Dinmont Solutions for 25 years. When senior management decided that Dinmont would become an Agile organization, they assigned Murcheson the task of overseeing a few preliminary projects to “work out the kinks.”
Murcheson’s first decision was to hire Hemmings, a product owner with five years of experience in Agile product development. The preliminary projects had a few minor mishaps but, overall, were very successful. Now management’s expectations had risen and the pressure was on to continue to produce results.
Murcheson shook his head. “I told Cranston that we locked the requirements when we planned the iterations, but he’s seen how we’ve been able to make adjustments quickly so he thinks we can just add the features anyway. I don’t think we have any choice. He’s not going to budge and he’s the boss. We have to get these features done.”
Question
Answer the question in the textbox, then click Submit to compare your answer to an answer written by an experienced project manager.
What options should Hemmings consider to deal with this change in scope?
Suggested/Sample Response
Hemmings will need to call the team together and explain the situation. He will need to get their recommendations and discuss options. They’ll have to scope out the work and determine if there is enough time left in the iteration to complete the additional features. If there is still time, they’ll have to decide which of the requirements already in the project can be swapped out for the new requirements. Any work that is in progress would not be a good candidate to replace, because all of the work will be lost, so they’ll have to concentrate on those work items that they have not started yet. And they’ll have to pick requirements that are approximately the same size as the ones needed to complete the new features. Hemmings will have to take the team’s suggestions under consideration but he, as the product manager, will need to develop the final options.
Hemmings will need to present Cranston with the options. If there is not enough time in the iteration to add the features, Cranston will need to decide whether to extend the release and delay the launch (assuming he has the authority to do so) or to include the new requirements in the next project.
Recommended for you Agile Leadership
