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.
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.
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.
There is no reason why requirements should necessarily be independent. In fact, the opposite is often true, especially for -ility requirements.
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.
Here, there is no difference between backlog items and good stakeholder requirements. Do not get me started on so called system or technical requirements.
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.
Some requirements are small while others are huge and in other cases we cannot even set a size (see above).
Not all requirements are testable. For instance, in the RAM RBS model only requirements on levels three and four are testable.
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.
- Venn diagram of requirements vs backlog items: Owned by the author
- Venn-diagram-of-requirements-vs-backlog-items: Owned by the author
Great information, I just bookmarked you.
Sent from my iPhone 4G
Pingback: DEEP backlog or Release-based Planning | Agile Project Manager
Pingback: Requirements Precision | Agile Project Manager
Pingback: Agile Project Manager » Blog Archive » Backlog Prioritization for Value Based Agile Software Engineering
Pingback: Agile Project Manager » Blog Archive » Agile and the User Experience
Pingback: Agile Project Manager » Blog Archive » You don’t Need “User Stories” to be Agile
Pingback: Agile Change Requests - Greger Wikstrand
Pingback: Software Effort Estimation Problems | Greger Wikstrand
Pingback: Agile Team and what is a Backlog ? Why are the backlogs for and why are they important | Agile and user stories
Pingback: Tester in Agile - Greger Wikstrand
Pingback: QA in Agile–How to Sync with team? | Abdur Razzak
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?
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 outany text that is linked to a non-functional target.