The normal entry point for scope changes on agile projects is at the end of sprints or iterations during the review of the product backlog at which time the customer would add new work items, clarify existing ones and reprioritize the backlog.
However, this is not the only way in which change can be introduced. Project team members could gold plate or even redo their work. The customer or other project stakeholders could also be influencing continuous change to the "what" or the "how" of the deliverables.
If these types of changes are not reflected as new items in the work backlog, the only indicator of the issue might be velocity metrics, which would illustrate that team productivity is dropping and that it would likely take many more iterations to complete the project.
So what are some methods that a project manager could employ to balance stringent scope control with a "free-for-all"?
- Ensure that high-level iteration planning includes a determination of how many iterations are required to meet the customer's minimal must-have requirements. Focus the team and customer on achieving this target, and then use remaining iterations as an opportunity to refactor and refine.
- Work with the customer to develop a performance incentive plan for the team that balances completing work on time and on budget with meeting all of the customer's requirements.
- Track iteration velocity and if it drops or is well below expected levels, dedicate sufficient time during the retrospective session at the end of each iteration to help the customer and team members identify likely causes. These reviews could include looking at what was expected to be completed during the past iteration and comparing that to the work items that were actually worked on by team members, and how many of those were redone or significantly modified.
Don't forget to leave your comments below.