Agile Requirements and the Agile Backlog

In agile projects we are supposed to keep everything we will do in our backlogs. The things we keep in there we call backlog items. With the help of releases, iterations, epics and stories we structure them into a work breakdown structure (WBS). Are backlogs enough to cover the complexity of building a major piece of software? In this essay I take a look at backlog items versus agile requirements.

Backlog Items

What is in the backlog? Backlog items of course, but what are they? In the beginning of the project backlog items are things like user stories, i.e. mostly functional requirements concerning the product to be produced written in the special “user story” style. An example:

“As a user, I want to be able to withdraw cash from my bank account.”

As soon as the project start, if not earlier, other things than functional requirements start to pour into the backlog. Things like change requests, bug reports and perhaps even planned team member abscence.

DEEP and INVEST

The backlog is an ordered list of backlog items. To have a useful backlog we need to keep it DEEP – Detailled appropriateley, Emergent, Estimated and Prioritized. In addition, each backlog item should be INVEST. A refresher about what INVEST stands for:

• I stands for Independence, the backlog item should be possible to develop independently, otherwise we cannot move it around in the development schedule
• N stands for Negotiable, the team should be able to negotiate the specifics of the backlog item with the customer. This affects schedulability as one of the things that can be negotiated with the customer is the scope and any further breakdown of the item.
• V stands for Vertical, your backlog should be divided based on a user perspective, not a systems perspective
• E stands for Estimated, unless your backlog items are estimated you cannot use them in scheduling your project.
• S stands for Small, unless your backlog items are small enough to fit several of them in one iteration, you will not be able to schedule efficiently.
• T stands for Testable, it should be possible to know when you are done with your backlog item by testing it. This affects schedulability as it defines when an item is done.

Agile Requirements

So, how well do normal requirements meet the requirements we place on backlog items? Can we safely and easily transform our existing requirements into backlog items? Dave Nicolette suggests that they can. I am not so sure, I believe that there are two or three obstacles to easily converting a requirement to a backlog item. These problems all stem from many requirements lacking INVESTness. Let’s look at each of the INVEST criteria to see how they create problems when we want to convert a requirement to a backlog item.

First of all, we note that six of the six INVEST properties are related to the backlog items schedulability and thus to their WBS related role while only two (iNvesT) are at least partly related to their specification role. Now, we shall take a look at each of these criteria as they relate to requirements.

Independent

There is no reason why requirements should necessarily be independent. In fact, the opposite is often true, especially for -ility requirements.

Negotiable

Prima facie, you would think that all requirements are negotiable. While most are, some are not. In fact most requirements are not even listed because all stakeholders see them as self evident.

Let me tell you a story about this. A friend of mine worked in the software division of a company making embedded systems. One day they got a new requirement. The hardware guys had tried to implement a feature but failed. Now they wanted the software people to solve it for them. My friend saw at once that the requirement was not computable and could not be met. Company leadership was not satisfied, implicitly they wanted to negotiate the computability requirement. They off shored all software development to more compliant software developers. (“Yes, I cannot…”) Needless to say, the company is no longer in business.

Vertical

Here, there is no difference between backlog items and good stakeholder requirements. Do not get me started on so called system or technical requirements.

Estimated

Again, while functional requirements might be simple to estimated, ilities requirments may not. They might impact every single other requirement with some small incremental cost.

Small

Some requirements are small while others are huge and in other cases we cannot even set a size (see above).

Testable

Not all requirements are testable. For instance, in the RAM RBS model only requirements on levels three and four are testable.

Conclusion

Source: Owned by the author
Many agile requirements do have a one-to-one relationship with backlog items while many backlog items are not requirements at all. See the adjacent image where I have tried to illustrate this. If having only a backlog is sufficient for you, by all means that is what you should do. If you do indeed have requirements which do not fit in the backlog then you should consider looking to modern requirements management models such as the RAM.