Scope creep in a project can be broadly categorized into two types:
Purely business and requirements oriented
Changes attributable to processes where the people and tools are involved in capturing and eliciting those requirements
This article covers how we approached handling and accounting for requirements that have changed within the release plan, as per the second point above. This is referred to as "discovered value" and includes:
Gaps identified in requirements
Implicit requirements elicited from show-and-tell sessions
This excludes a fresh set of requirements, including enhancements to existing functionality, because of a change in user requirements with reasons such as changing laws with time.
We have a distributed team working across geographies, and the teams also consist of different vendors for the build and test function for a very large UK bank. Most of the project team is sourced from different functions (technical or business) to deliver a project. Given the constraints, the organization has been experimenting with various Agile models with customizations that meet our current needs.
Identifying the problem
While planning for a release, the planning covers the business value of a product/release backlog. One of the challenges we face is not being able to plan for discovered value (as described above) for our projects. As the discovered value is identified very late in the project life cycle, it pushes the plan and impacts business readiness as well as value delivered.
A pilot was conducted for three in-flight projects: a large, complex project (project 1); a small project (project 2); and another large project (project 3). The three separate projects were of varying team size and were executed by different teams. There are many available and popular metrics that can be used to measure scope creep for function points, feature points, and use case points, to give a few examples. In our projects we were using story points.
As part of release planning, we assigned story points to finalized requirements. This became the baseline for the project. Once we were into sprints, each project team assigned additional points for discovered value.
Findings and use
While we cannot plan for everything, the data above gave us confidence that we had to plan for discovered value. There would be other initiatives that would work to bring effectiveness to the current set of processes and tools to help reduce variability in discovered value. While those other initiatives are taking shape, we have started using the data above as a baseline for release planning for similarly sized projects for our group. We have also started building our repository, and as more data points get added we expect to observe a pattern for the discovered value. This gives all our stakeholders a base for planning any additional time for marketing, customer readiness, and IT build; it also helps plan the corresponding budget because of anticipated discovered value.
The other thing that we noticed is that discovered value toward the end had more impact on time lines (nonlinear) because of nonavailability of people to resolve queries on time.