Requirement Churn

There are times that we discover parts of the User Story no longer relevant since the time of the Story was written. There are times the User Story is morphed into something completely different when we start working on it. When that happens, I would step back and think why this is happening. One possible explanation – we are suffering a case of Requirement Churn.

Requirement Churn is usually a symptom of gathering requirements too early. When one is trying to gather requirement for features of a system that will not be built until later, one must “predict” how the system will behave in the future. The farther ahead in the future we are gazing into, our vision becomes more blurry. That is our accuracy of prediction diminish. The inaccuracy is caused either by predicting too far ahead or by predicting too much detail about the future system. We should consider cost of these inaccurate prediction.

The diagram above describes activities of an example project. Notice, this particular project has a long Release Planning period. Release Planning took nearly the same amount of time as the total development time (4 iterations). This indicates the Team is a bit risk averse and it tries to “nail down” requirement.

This Team release their software after 4 iterations. Some of the features that was originally discussed in the Release Planning meetings did not get implemented (in grey) either due to lack to time or the Customers decided they no longer need those features for the release. Much of the requirement gathering and planning effort was wasted for this release.

During Iteration 3, the Customers decided to implement some features that was not in the original plan (in red). The Customers are anxious to get those features in. As a result, some of the assumption in the original Release Plan was invalidated. Costing some re-planning activities.

A way to reduce Requirement Churn is having shorter release cycles. When release cycles are shortened, the scope of each release is reduced. Release Planning effort is reduced because there are less User Stories to be considered. Consequently, by reducing the wait time for the Customers to get their hands on their product, the likelihood of “out scope requests” is reduced. To the customer, knowing the next release(s) is coming around quickly, it is less risky to defer features into later releases.

My 2 cents: In current uncertain economic climate, I think more CIOs and IT managers have appetite for small scope, short releases and less risky projects 🙂