PM Articles > Alan S. Koch > The Essence of Agility: Progressive Requirements Elaboration

The Essence of Agility: Progressive Requirements Elaboration

The Essence of Agility
What makes a project "Agile"?
Part 5: Progressive Requirements Elaboration

by Alan S. Koch, PMP

They say that they are "Agile," but it just looks like hacking to you. How can you tell? The Essence of Agility consists of those sets of behaviors that distinguish a truly Agile team from a bunch of hackers claiming to be Agile.

In my last four columns I addressed five of the key behaviors essential to Agility in projects: Learning and adaptation, collaboration, customer focus, small self-directed teams, and embracing Lean principles. In this article, I will address the next key characteristic: Progressive Requirements Elaboration.

Why "Progressive"?

In the first installments of this series, we discussed three important behaviors of an Agile team. Each of those three behaviors requires a change to the way we elicit and manage requirements.

  • Learning and Adaptation: If we accept that predictive planning is inappropriate, then we must not expect that we can nail down all of the requirements at the beginning of the project. Both our customer and we will be learning about the requirements as the project moves forward, so our collective understanding of the requirements must adapt to that learning.
  • Collaboration: A big part of the regular collaboration that must happen on an Agile project centers on the requirements. We must constantly be re-checking our understandings, and be open to new and changed details as the project progresses.
  • Customer Focus: If we accept that satisfying our customer is paramount, then we must be willing to adapt to their changing needs. Sometimes the change is merely a matter of our customer refining their understanding of their needs. But sometimes they experience real changes in mid-project. Either way, the requirements must adapt to those changes.

Project vs. Customer Needs

If we are to focus only on our customer's needs, we might decide that no requirements should be documented. That way we would have ultimate flexibility in reacting to our customer's needs!

But that approach is insufficient because it gives us no basis for planning and managing the project. We need an understanding of what the project is supposed to deliver so we can ensure that appropriate resources and time are being brought to bear. (That is why we like big up-front requirements with sign-offs!)

Progressive requirements elaboration allows an Agile team to balance their customer's need for flexibility with their own need to plan their work. Although there is no simple formula for how an Agile team does its work, we will use Scrum (one of the Agile Methods) as our touchstone in talking about this behavior. (Please note that your team may not be precisely following these steps, but may still be taking an Agile approach to their requirements.)

Progressive Step 1: Product Backlog

The very first step in a Scrum project is for the team and their customer to collaborate to define the Product Backlog. Note that the word "backlog" does not connote being behind schedule or any other negative idea. The Product Backlog is the team's best understanding of a complete list of the names of the requirements for the project. Think of each item in the Product Backlog as the title of a requirement with no further information.

The purpose of this information is to meet the team's need for a basis of planning. Each backlog item will be a deliverable of the project, and so the project will require the sum of the time and resources required to produce these deliverables. After the customer prioritizes the backlog items and the technical team produces a ROM (rough order of magnitude) estimate of each, a broad plan for the flow of the project can be produced. I call this the Project Roadmap.

Although the Product Backlog is produced at the beginning of a Scrum project, it is never treated as final. The customer and the team can add, delete, re-define, re-prioritize, or re-estimate backlog items at any time. And of course, significant changes to the Product Backlog will result in changes to the Project Roadmap.

Progressive Step 2: Iteration Backlog

The Project Roadmap does not provide the information that the Agile team needs to manage their work during each iteration. In order to produce their iteration plan, the Agile team will usually require a more detailed understanding of the Backlog Items that will be addressed during that iteration. So, as a part of iteration planning, the team and their customer discuss each requirement for that iteration in much more detail.

Different Agile teams capture this more detailed information in different ways. Some write one or more Use Cases for each requirement, and others simply make notes on the Story Cards. Some teams don't capture the additional detail in written form at all, preferring to rely on memory. (I don't recommend this reliance on memory because … because … I can't remember why.)

The Scrum team's Iteration Backlog consists of a list of the work they will do during the iteration in order to deliver the Product Backlog items that have been selected for that iteration.

Please realize that the nth level of detail about the requirements is not elicited and documented at this point. The team only needs enough requirements detail to plan the work they will do over the next few weeks. However, if the team's customer is not Agile and will not be available for Progressive Step 3, then the team must try to capture detailed requirements at this point. (This compromises agility, so it should be avoided if possible.)

Progressive Step 3: Writing the Code

Many of the details in a Requirements Specification are not needed for planning, but are there to direct the coding effort. An Agile team will elicit those details from their customer as the code is being written. Naturally, this would necessitate that their customer is available to them continuously—or at least regularly.

Because these detailed requirements don't need to be recorded for future use, Agile teams usually document them not in a Specification, but in some more usable and actionable form. Examples that are seen on many Agile projects include:

  • Test Cases: When the customer says "It must work this way," test cases are immediately written to capture that information. When the tests pass, the code is correct. (This is called Test-Driven Development, or TDD, and is a very good quality practice!)
  • Self-Documenting Code: While test cases capture what the software must do, they may not provide sufficient background information about why. So, Agile teams will adopt coding standards that result in code and comments that make the programs as readable as any specification would be.

Becoming More Agile

Progressive Requirements Elaboration goes hand-in-hand with the last two behaviors, Incremental Delivery and Iterative Planning & Adaptation (which we will discuss in the last installments of this series). Requirements can only be approached progressively in a project that is run as a series of discrete steps that are not fully defined and planned predicatively.

The biggest challenge in adopting Progressive Requirements Elaboration lies in helping your customer to understand how this new approach works, and how it benefits them. We must emphasize the flexibility that this approach provides for them, and the degree to which it guarantees that the product we deliver will be precisely what they need. Only then will they be willing to make the investment of their own time that this approach requires.

Related Links
Requirements Cards are just one way of capturing backlog features without excessive documentation. Detailed test plans are a best practice for any project, agile or otherwise. Kent McDonald has explored the Agile concept of continuous customer involvement and the "single wringable neck," and explains why sometimes just one person isn't enough.

Not all comments are posted. Posted comments are subject to editing for clarity and length.

This is something really good in this package.

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.