Improve Project Delivery with Better Scope & Requirements Management - An Agile Aid

Post date: Jan 5, 2015 3:13:32 PM

Scope definition and clear requirements are of tremendous importance for the efficient delivery of software projects. If we take into account the requirements pyramid we can distinguish two levels: the problem domain level, containing stakeholder needs and then the solution domain level containing epics, features that are captured in the product vision and in the product backlog and at a more technical level we have the software requirements derived from features which are quantifiable and estimable with acceptable accuracy.

Agile approaches with their two-level planning horizons (release and iteration) can help improve requirements management and ensure that the required scope is delivered. As expected, this is performed via a continuous improvement process by collecting metrics at iteration and release levels respectively, by ensuring continuous reflection and by the measurement of the business value delivered to the client.

Let's explore the metrics that are relevant for this purpose at these two core planning levels as part of the retrospective rituals taking place at the end of each iteration or release.

Iteration - Quantitative Assessment

Two dimensions will be analyzed: the functionality and the quality and test automation.

Functionality is the means through which scope is delivered and in Scrum it takes the form of user stories. What is important to capture at each retrospective in order to improve requirements management?

The following metrics for each iteration will help measure, assess and improve the current scope & requirements delivery:

1. 1.Number of user stories loaded at the beginning of the iteration
2. 2.Number of user stories that have been accepted in the iteration
3. 3.Percentage of the total user stories that have been accepted
4. 4.Number of user stories not accepted because they were not achieved as part of the iteration effort
5. 5.Number of user stories that were pushed to the next iteration
6. 6.Number of user stories that have been deferred to a later date
7. 7.Number of user stories that were added during the iteration

If we look above, metrics 4, 5, 6 and 7 captured in various sprints will deliver a track record of the causes for requirements instability due to prioritization and scheduling issues helping the reviewer of these metrics to focus his attention on improving these areas.

The second dimension is the quality assurance and the test automation because they are linked directly with the required levels of quality for the functionality delivered to the customer. The collection and assessment of the metrics for this dimension at iteration level will help improve the quality assurance process, the end goal being a 100% automation of the test cases meant to ensure required levels of quality and accelerating regression and explorative testing at the same time. Here is a list of the most important ones:

1. 1.Number of user stories with test cases available (either automated or manual)
2. 2.Defect count at iteration start
3. 3.Defect count at iteration end
4. 4.Number of new test cases
5. 5.Number of new automated test cases
6. 6.Number of new manual test cases
7. 7.Total number of automated tests
8. 8.Total number of manual tests
9. 9.Percent tests automated
10. 10.Unit test coverage percentage

This dimension helps tracking the automation degree of requirements validation according to the previously agreed acceptance criteria this way contributing to the overall scope validation and issue management improvement in general.

Going from the bottom (iteration level) up (release level) we can track more high level metrics with regards to scope and requirements management. Again, two dimensions are important.

The first dimension is without any doubt, value delivery. Metrics captured for this dimension helps tracking release delivery to the plan and measures the business value that has been created through software.

1. Number of features delivered in the release
2. Number of feature points delivered in the release (weighted features by value)
3. Planned release date
4. Actual release date

Comparing these metrics for different release for a longer period of time helps track release alignment with target business objectives and customer satisfaction.

The second dimension is on a more hidden, technical side that is also important and relevant in order to accelerate time to market and in order to optimize internal software delivery processes. This dimension is the architecture and feature debt which can be assessed in quantifiable manner using the following metrics:

1. Number of refactors completed
2. Refactor backlog (total refactors)
3. Customer debt (promised features) that have been delivered
4. Total customer debt features

As listed above, one can see that this dimension unifies the internal technical efficiency of software delivery with the less quantifiable customer satisfaction modeled with the concept of customer debt referring to the outstanding features that are demanded by the client market. Looking at these numbers for a certain number of releases, an action plan can be derived in order to improve organizational ability to adapt to various market demands of its customers.

In conclusion, agile metrics focusing on two planning horizons and on two dimensions can provide a consistent picture which helps deriving an action plan towards improving software delivery and thus determining better customer satisfaction.