BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Opinion: The Implicit Backlog

Opinion: The Implicit Backlog

Last week, we reported on the wastes that are attributed to having a Product Backlog.  This week, to keep it interesting, we'll report on the wastes present when a Product Backlog is absent.

I have been working with a group adopting Agile practices in their organization.  They happen to be a services group - one that builds internal software for other groups (not necessarily software groups) within the organization.  One of their main problems happens to be that they have not been successful in getting all of the stakeholders to agree on the priorities of their requests - each group sees its request as being important.  And, by the way, they want all of the requirements done.

This scenario is not an uncommon one in the industry: a development group has multiple clients and each client has its own priorities.  Unfortunately, many such groups are unsuccessful in creating one backlog because of the difficulty of getting everyone on the same page.  So they have an internal prioritization and have frequent interrupts depending on the size of the fire that needs to be put out and the volume of the speaker on the other end of the line.

After a good discussion the team realized that every team really does have a backlog - even if it is not explicit.  There is only one order of execution of tasks, even if there is no physical, visible, backlog - that is, there is an implicit backlog in each and every project (Agile or not) that is determined by the execution order.

They have decided to be explicit about their backlog and make it visible to all their clients.  They are expecting their clients to become interested in getting involved in the maintenance of this backlog over time as they see the team executing to the project. 

There are, of course, other ways to go about this.  For example, a report from the BBC team at Agile 2007, expressed their experiences with multiple backlogs and their attempt at one product owner.  Clinton Keith wrote up a good summary of the problems and one set of solutions with this approach.  Mike Griffiths describes how a Project Management Office (PMO) can interface with multiple Agile projects via their backlogs.

Do you have an implicit backlog between your multiple projects because it is just too difficult to have one and only one backlog?  Is it wasteful?  How have you addressed the issues?

Rate this Article

Adoption
Style

BT