Do Requirements Really Change?

In my last post, I discussed change and how it is always present in projects. In this post I would like to discuss a particular area of change: what we often call changing requirements. Changing requirements are typically blamed for most ills in software projects. How can this be resolved with my earlier assertion that change is useful? We’ll give it a try.

I asserted earlier that one might consider embracing change. Get to know it better. Become intimate. So let us look at what is often meant by changing requirements.

A way to describe changing requirements is that the requirement R was ABC and now it is ABZ. Damn. It changed. The key word in this description is ‘now’. Exploring the issue of time in changing requirements is important.

Now we all understand that the cost of change is higher the later the change is in the development process. Correct? Typical numbers are that it costs an order of magnitude more as you move through each phase: requirements gathering, design, implementation, or deployment. But this is derived from phased thinking. If much shorted cycles are used, as suggested by agile development, then the temporal distance is much shorter. In other words there is much less opportunity for change. Woo-la, we have less changing requirements.

‘But: but: .but’ you say. ‘Things will change even so. ‘ Yes. I agree. But those changes are really new requirements and must be treated as any new requirement. New requirements are more easily noticed as something that may have a negative impact on schedule. Changing requirements are not so easily noticed as such.

In agile development we typically ask that the work be set for the duration of the iteration or sprint, typically 2-4 weeks. This means no changes in requirements during the iteration for the work being done during the iteration. Work to be done in the future is free to change as much as needed.

Now I have simplified a little and there are other issues that surface when this occurs. But in general what I suggest is true. By adopting time-boxed development we have changed the changing requirements problem to a new requirements problem.

And something else shows up. When we adopt this technique, the work must be specified in smaller hunks, often called stories in agile development. The construction of these smaller hunks also gives us leverage in changing requirements.

Remember our requirement R? It initially was ABC. If we have to decompose it, it will result in three stories (sub-requirements, features, use cases, stories: it is a fractal, repeating process) we can call Story A, Story B, and Story C. When the change in requirement R is made we see that Story Z is replacing Story C. If only stories A and B have been completed then the change has very little cost. If story C has been completed then Story Z is just a new requirement.

Another situation occurs when development discovers that implementation of some requirement is unexpectedly delayed. It may be much harder than estimated, the critical resource is unexpectedly not available, or any of a large number of thing that can happen. Since agile is time boxed a good agile team will negotiate with the PM to reduce the scope of the work. This is done in order for the team to deliver some value, perhaps not as much as planned but more than nothing.

In this case the work will be split into what can be accomplished in the iteration and what will be put off until later. I prefer to think of it as creating a new requirement or budding off a new requirement. The new requirement is really new only in the sense of tracking. What has surprised me is how often that new requirement is often not the next most valuable thing to be done.

This mechanism of splitting and decomposing aids considerably the work at finding the highest value work to be done next. Think about how this might apply to your projects!

Share

3 thoughts on “Do Requirements Really Change?”

  1. User Avatar

    Sandra, the link Jeff provided is a very good example. My group started using SCRUM a little over a month ago, and I’ve personally used an iterative approach like SCRUM in the past on projects unrelated to software development. The key thing is to use each sprint (or cycle) to produce a version of the deliverable, whatever it may be.

    For instance, I work a lot of projects where the end result is two disparate systems talking to each other. This is definitely IT/IS work, but there is no true user interface that we’re developing on those projects. Instead, we use automated distributions of various helpful analysis of the data. During the development phase there is a period of time doing the initial design and setting up the ‘validation data’ exports. Then, the data is distributed automatically on a daily basis. We meet with the business and find out what the issues are….each day we can be making adjustments to the design, and the next day new data comes out with the changes implemented. By the time we get to the cut-over date, everyone is very confident in the design.

    I think this is similar to SCRUM where you might do the most important functionality in the first sprint, then tweak and add features in the subsequent sprints. At the end of each sprint, the stakeholders have something to look at and give feedback on.

    If you’re changing a process at UCSC, you can plan for the first cycle, then see how it works, do another cycle, see how it works, etc. until the process is where you need it to be. The main thing is having something to measure at the end of each cycle, whether qualitatively or quantitatively.

    My $.02

    Josh Nankivel
    http://www.PMStudent.com

  2. User Avatar

    Not sure exactly what you mean. What are you trying to manage.

    Agile project management, especially as described by Scrum is not limited to software development. It has been used successfully in other areas.

    Go to http://www.leanconstruction.org to see some very interesting papers on using these techniques in the construction industry.

  3. User Avatar

    It seems that agile project management would be very appropriate to UCSC Extension. Do you think this could be applied to an educational institution? How would it vary?

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top