Do you even need a product backlog?

A great question was posted on scrumdevelopment group, worthy of discussion. The question posed ...

Summary

Their business moves very quickly and, more often than not, any stories that enter a sprint will have been thought up and written up maybe only two or three days before a meeting of the stakeholders and the product owner to decide what the priorities are. Anything that doesn't make it into the list for them to estimate and add to the sprint will go on the product backlog, but will generally not be looked at again for a while, if ever.

Question

To this end, our backlog is ever growing with stories that, in all likelihood, we'll never work on. Based on this, should we even bother with a backlog?

Response

Long backlogs in Lean thinking represent waste. Especially given the picture painted by this use case. Long outdated product backlogs means someone in the organization has to go through it and  keep it groomed. The longer the backlog, the longer the time required to keep the backlog updated and if it's really ever used, why bother. Important requirements will always surface again.

I personally hate not recording stories as I am always concerned that a great idea will just get lost and forgotten about. But this does lend to wasteful behavior and work.

In this scenario, it's seems like their just-in-time story elaboration is working well. So I would be inclined to recommend that they drop the notion of a product backlog. Or perhaps triage only really high priority ones onto the backlog.

Thoughts?

Jack

Comments

[Bruce Onder]

I'm working to help a friend get a software project off the ground, and we are doing what I would call lean product backlog development. We only have a small handful of stories in the product and sprint backlogs combined (in fact, I wouldn't even call it a sprint backlog but a kanban board).

It's working great. We only design what we want to build, and only when the developers need another story to start working on.

[Craig]

In the context it makes sense.

We have a growing backlog on several of our enterprise systems (aka products) and we know roughly where the "It'll never happen" line is.

On the one hand taking stakeholder suggestions and loading them onto the backlog is useful in managing their expectations. On the other hand there is a defineite "It'll never happen line" an maybe there is waste here.

Lastly, the backlog's main purpose is for estimating right? So if you are in ongoing product dev mode you don't really have an end date, but in many enterprises there is a budget and deadline to work with.

[Jack Milunsky]

@Bruce, good job!

@Craig, I wouldn't say that the purpose of the backlog is solely for estimating. Its there as a collection of work yet to be done and for the Product owner to slice and dice to determine priorities.

Jack

[Chris Davies]

I think this approach works if - and only if - you are dealing with small Production changes or maintenance stuff. On a complex project you absolutely need to write stories - even high level ones - for the entire project. That's the only way you can put individual stories in context, establish sensible priorities, identify your desired architecture, the need for specialists in the team, the need for analysis on some stories... need I go on?

It's good to limit your sprint backlog, but for the whole product or project? No way! This has the effect of limiting the thought that goes into the 'big picture' and constant correction and re-prioritising.
I believe you absolutely must have stories that cover the entire breadth of the product/system/project, if not the depth. That can come when you need it, like at the start of each sprint.

@chrisdavies62

[Luiz Claudio Parzianello]

I've seen this problem on my customers mainly when we face two situations:

1) A business roadmap (a value delivery plan) is not defined for the project (you think only to develop a product but without the notion of the transformation you will do to the environment context); so, there is no policy to add new features to the Product Backlog;

2) The Product Backlog is not managed in terms of a SLA (time to review unused information, for example) and 5S's (requirements classified, stabilized, cleaned, standardized and sustained); the consequence is a pile of requirements (inventory) and a waste for the process; the 5S's technique has been very useful to manage the requirements repository;
Working for improvement on requirements management based on these policies has been shown very effective in many situations.

Parzianello

[Jack Milunsky]

That's the first I hear of the 5 S's. Perhaps you can point us to more information on this topic.

I have personally never managed a project without a backlog. But after reading the Lean book by Mary and Tom Popendiek where they go into great lengths to explain the 7 wastes, it does make me wonder if most of what's on the backlog is just a waste. I know for example one the Agilebuddy backlog I know there's stuff there that we'll most likely never ever get to. So why keep that on the backlog. It's just noise making teams less efficient.

At least it's food for thought.

Jack

[Dot T]

I agree with Chris Davies about getting the scope “up front” to put individual stories and architectural decisions in context and Parzianello’s 5Ss are useful to remind us that requirements do change.
I think Agile projects often lack the real concept of a project: an endeavour with a start and an end, to a particular purpose (objective), with a budget and a deadline. We need to build in chunks, but from a firm foundation. We also need a clear business focus to allow prioritisation of what we work on. The only Agile approach that really addresses the project concept and allows for innovation and the discovery of new requirements is DSDM Atern. The MoSCoW prioritisation, including a definite “Won’t Have” category gives control over burgeoning backlogs.