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 DEEPDetailled 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


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.

Image sources

  • Venn diagram of requirements vs backlog items: Owned by the author
  • Venn-diagram-of-requirements-vs-backlog-items: Owned by the author

About Greger Wikstrand

Greger Wikstrand, Ph.D. M.Sc. is a TOGAF 9 certified enterprise architect with an interest in e-heatlh, m-health and all things agile as well as processes, methods and tools. Greger Wikstrand works as a consultant at Capgemini where he alternates between enterprise agile coaching, problem solving and designing large scale e-health services

15 Comments

  1. Great information, I just bookmarked you.

    Sent from my iPhone 4G

  2. Pingback: DEEP backlog or Release-based Planning | Agile Project Manager

  3. Pingback: Requirements Precision | Agile Project Manager

  4. Pingback: Agile Project Manager » Blog Archive » Backlog Prioritization for Value Based Agile Software Engineering

  5. Pingback: Agile Project Manager » Blog Archive » Agile and the User Experience

  6. Pingback: Agile Project Manager » Blog Archive » You don’t Need “User Stories” to be Agile

  7. Pingback: Agile Change Requests - Greger Wikstrand

  8. Pingback: Software Effort Estimation Problems | Greger Wikstrand

  9. Pingback: Agile Team and what is a Backlog ? Why are the backlogs for and why are they important | Agile and user stories

  10. Pingback: Tester in Agile - Greger Wikstrand

  11. Pingback: QA in Agile–How to Sync with team? | Abdur Razzak

  12. Magnus Karlsson

    But when I take a user story and break it down to tasks, the tasks for different user stories will be very similar which only can be resolved by developing the task common for several user stories at the same time. THIS is one of the hardest things for agile teams, to know when to break the rules and still be agile.

    • You are right, this is indeed a challenge for “purist agile”. What are the workarounds that you usually use?

  13. WF Zimmerman

    What’s with the strikeouts on the epics and stories? Coming in without context, I have no idea why you are “deprecating”? those concepts.

    • It’s a feature in WordPress… It strikes out any text that is linked to a non-functional target.

Leave a Reply