Working with Discovered Value

Agile Planning and Estimation

20 February 2014

Ritesh Gupta
Tata Consultancy Services


Discovered value

Scope creep in a project can be broadly categorized into two types:
  1. Purely business and requirements oriented
  2. 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
  • Design gaps
  • 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.

Background

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.

Approach

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.

Article Rating

Current rating: 0 (0 ratings)

Comments

Hemant Gokhale, CSM,CSPO, 2/24/2014 12:36:33 PM
This is interesting study. This metrics can also be captured in projects where velocity baseline is derived from some initial sprints and then this data is used for deriving time/scope estimate for rest of the of product development. This additional information of %discovered value along with velocity from initial sprints, will help to improve accuracy of the estimates.

You must Login or Signup to comment.