Implementing this approach requires only a minimal set of data, and you can start the process at any time in the project.
In my example I have tracked the requirements weighted with their development effort. But here is another example of the same data with the estimates removed and instead only the number of requirements tracked.
The difference is the Y axis scale has changed, but otherwise everything is the same.
The reason for this is that the average size of requirements tends to be the same. In some projects you may find this to be different. Many people practicing lean software development track story sizes with a three categories such as small, medium and large. They can then watch how weightings of small or large sized requirements can change patterns in predictable delivery.
Again, I recommend you start simple, and use the data that is easy to hand.
Simply tracking the number of live requirements on a regular cycle will give you some insight into the likely size of the target when the project meets its deadline.
- Number of live requirements
- By month
- And status (Done/ not done)
You may or may not be able to track work done by developers as they complete components and features, rather than only at project stage gates. If you can get this information, you will see when the work is actually likely to be completed. Or what features will be completed by the deadline.
And once you have this information you can talk to your stakeholders and project team members about the options available to you.
Do you start working on managing people’s expectations down, do you cut quality? Do you cut features? Do you ask for an extension?
The right approach depends on the circumstances of the project of course. But with good information you can have better conversations.