Given that the scope of work may evolve after discovery, how do you manage change during the project life cycle?

Change and evolution of requirements are inevitable. We may think we know what users will want and need – in fact, users may think they know what they want – but it is only after we deliver functionality, get it into the hands of users, and solicit their feedback can we confirm if the software delivered meets expectations. So, we need to expect and embrace change because it implies that we are gaining insight, making new discoveries, and uncovering emerging issues.

We are an agile software development team. Agile has emerged as the preferred software development methodology specifically because nearly all software development projects face changing and evolving requirements over the course of the software development life cycle. In fact, the three truths of agile development are:

  1. It is impossible to know or collect all requirements
  2. Requirements are likely to change over time
  3. There will never be enough time or money to do everything

Therefore, we must be agile. The underlying premise of agile is that requirements are fluid, not fixed, and we need to prioritize requirements to ensure that when time and money eventually runs out, we will have delivered the most important features and highest priorities at that time.

Agile also means that we manage and prioritize the project variables, which include:

  1. Number of features
  2. Quality of features (usability, accessibility, security)
  3. Deadlines
  4. Budget

What this means is that if the scope of work changes or if things are taking longer than expected because of changing requirements, then we may need to relax one or more of these project variables. It could be that we focus on delivering many features even if those features are not user friendly (quality of features). Or, it could mean that we deliver fewer features because we focus more time on usability (quality of features). It could also mean that we must deliver some features by a certain date (deadline) so we may have to sacrifice quality. Usually, only one or two of these variables can be fixed, the others may need to be variable if we are going to be agile.

An agile technique, called backlog grooming, allows us to clarify user stories (requirements) and prioritize (or reprioritize) those user stories so we focus our efforts on the most important and highest priorities at any given time. Backlog grooming peels back the layers of the onion on requirements and allows us to see things more clearly. At a minimum, we should perform backlog grooming once a month.


Related Posts