Most modern methodologies talk about incremental and iterative processes, but surprisingly few projects operate this way. Why is this? Everybody is talking about it but nobody doing it?

One symptom I see is that a team will say they are doing incremental and iterative development, but their project timeline says different, there is a large chunk of time up front for “Analysis”. Inside this “Analysis phase”, the activities are familiar.

  • Use Cases for Requirements capture
  • Some modeling to understand the problem domain
  • Some designing of possible solutions

After a few months of this, the time comes to move into the incremental and iterative development process. But after working in a sequential phased approach, the team is not ready for short cycle incremental development! After all, a team can only get good at what it practices.

Another common symptom I see is that the “Analysis phase” takes so long that the other activities necessary to deliver the software have to be compressed to meet the deadline. Then the team is left in the unfortunate situation of facing a death march, and the client is left with complete requirements documentation and a partial implementation (if they are lucky). An even more common outcome is great requirements documentation and no system to show for it. “ Well, we now understand what we need to build, but unfortunately there is no budget left to build it.

A third symptom I see is that by the time a team comes to start working on a requirement, the business has moved on and the development team is left struggling with the issue of “ Scope Creep ”. Capers Jones suggests that requirements change can easily be 1.5% per calendar month of project duration. To fix this we need to reduce the time span between Requirements Capture and Implementation .

A solution to these problems is to adopt an incremental requirements process as well as an incremental development process. This is possible because it takes much less time to identify and prioritize a requirement than it does to capture all of the implementation detail.

So Capturing Requirements for Prioritization is a cheap process that can occur up front in a project. It can also be ongoing whenever a new requirement is identified, all that has to happen is that the new requirement has to be inserted at the appropriate place into the Work Queue .

When a requirement gets to the top of the Work Queue, then it gets subjected to the Capturing Requirements for Implementation process. This (obviously?) takes longer than the prioritization activity, but we now have a mechanism for Incremental Requirements Capture .

Using Incremental Requirements, a team could spend a few weeks at the start Identifying and Prioritizing Requirements . Then they can start on a truly incremental development process, delivering the top few requirements every couple of weeks .

Is this really feasible? The success of eXtreme Programming gives one answer. Another answer is to look at the effort required for the different activities needed to support Incremental Requirements .

Effort to identify and prioritize a Requirement as a Use Case or Story that needs to be implemented

2 to 8 person hours

Effort to fully capture and document a Use Case in all of the gory detail needed for implementation

1 to 4 person weeks

Effort to develop, test and document the functionality within a Use Case

1 to 4 person months

The ranges of values are what I observe in projects. Few projects manage to come in under the lower bound, many projects easily surpass the upper bound by assuming that they can beat the lower bound.

For a sample 40 Use Case project, prioritization will take 2 person weeks to 8 person weeks, capturing the implementation detail will take 40 person weeks to 160 person weeks. Implementation will take 40 person months through 160 person months. So rounding up the total project will take between 50 and 200 person months, say 4 through 16 person years.

With a team of 8 developers, we are looking at 6 months to 2 years of calendar duration.

With the standard Analysis phase , the team will be busy doing analysis for between 2 and 5 months, assuming all developers are good at requirements elicitation . Typically this is not true, so often a team will start with a small core of analysts and grow in size when development “proper starts”. Under this scenario, we could easily take between 4 and 8 months to complete the Analysis phase.

With Incremental Requirements, the numbers look totally different. Assuming only 2 developers are good at requirements elicitation, we need 1 to 4 weeks of calendar time to prioritize the requirements. Then assuming 4 Use Cases per increment, each increment needs between 5 and 20 person months of effort. So every 3 weeks to 3 months you can have a useful increment of functionality.

The contrast is between the two approaches is extreme (sorry). With a full blown incremental approach, we could deliver 30% to 50% of the total functionality before the Analysis phase is completed.

The numbers are even better with eXtreme Programming. A User Story is much finer grained than a traditional Use Case, so capturing the implementation details can occur in conversation with the users who are part of the development team (the work content is mostly the same, it just happens during the development task). So after the initial prioritization phase, every 3 weeks the development team churns out more functionality. So the team could have delivered 33% to 60% of the total functionality before the Analysis phase is completed.

More good news. Scope Creep does not affect us, since the business gets to pick the top priority tasks for us to work on next. If the requirements change for something that is already delivered, the team will work on it when the business make it a priority.

We avoid a Death March , since we are delivering partial functionality early. Developers and the Business can see the realities of the delivery process and can predict accurately when development will be complete.

The team gets good at the Incremental and Iterative process , because that is what they practice all of the time.

Overall a win for everybody, all achievable by separating the concepts of Capturing Requirements for Prioritization from Capturing Requirements for Implementation .

The author can be contacted by e-mail at or the Wiki Website.