As you can see in the Intake Work process goal diagram of Figure 1, there are four fundamental strategies for managing your backlog of work. These strategies are ordered, you know this because there is an arrow beside the list, indicating that the strategies towards the top of the list are generally more effective than the strategies towards the bottom. In order from most effective to least effective, these strategies are:
- Lean backlog. Lean backlogs are typically organized into four groupings: Potential work that the team may commit to; Committed work that the team will perform, which is typically sequenced into several classes of service; Work in process (WIP) that the team is currently performing; and completed work that is ready to move on to the next stage in your overall process.
- Agile backlog. Work items are managed as an ordered list/stack. Higher-priority work items appear at the top of the list, are granular and captured in greater detail, and are sequenced. Lower-priority work appear towards the bottom of the list, lack detail, and are effectively in unsequenced priority buckets. In previous versions of DA we referred to this strategy as a Work Item List and it has always been our default recommendation for agile team. This strategy was an extension to Scrum's (at the time) product backlog which was a prioritized list of requirements, but over the years Scrum's approach has evolved into this more disciplined strategy.
- Requirements (product) backlog. A unique, ranked stack of requirements that needs to be addressed. Requirements at the top of the list should be captured in greater detail than lower-priority requirements at the bottom of the list. In earlier versions of Scrum this was a prioritized list of functional/usage requirements, often captured as user stories. Some teams would include defects and some form of quality requirements (often captured as technical stories) on the backlog, as they were considered valid requirement types as well.
- Unsequenced backlog. All of the work is effectively the same priority, although sometimes there may be the concept of two priorities - what is in the current release and what needs to be in future releases.
To learn more about your options captured in process goal diagrams, including Figure 1, use the DA Browser.