This has been annoying me for years as well. A backlog is a list of things that should have been done by now but have not. A plan or roadmap is a statement of what should be done in the future. I never understood how this term became currency when there were plenty of better, existing ones.
The argument seems to hinge on the idea of backlogs being work that must be done, but that seems weak.
First, not all of the definitions explicitly include the concept of "must". Of the 5 definitions, only ChatGPT's ("need to be") and Cambridge's ("must do now") include the idea of "need" or "must". The argument that a backlog is work that must be done doesn't seem to hold up when 3/5 of the definitions don't support it.
I also think the idea of "need" or "must" is different in an agile context. A hallmark of agility is responding to a changing environment. At a given point in time, the backlog represents the set of work that people believe "needs to be" done or "must be" completed. However, by doing the work and collaborating with stakeholders, we'll find things that must be done that we didn't think of or learn that something we felt was needed isn't. Just because we believe something must be done today doesn't mean we'll continue to hold that belief tomorrow once we see something that changes our minds.
If something won't be done or doesn't represent something someone thinks is necessary, there's no reason to put it on the backlog. Work that is far beyond the current vision for the product, for example, doesn't need to appear as an idea or option.
I see it differently. Each of the five definitions IMO communicates an expectation that the work will be done. And that is exactly how many clients will interpret the product backlog. While it would be much better, for expectation management and to prevent disappointment and endless discussion, to communicate the intent with different terminology.
This feels like an experience thing. I've never met anyone who understood that there was a commitment to finish everything in a backlog. This is especially true after explaining the agile perspective on vision, emergent work, and built-in change management/control, rather than a comprehensive requirements specification.
The terminology around backlogs is already well-entrenched. I struggle with the idea of new terminology without a better understanding of the category of people who have incorrect expectations and whether a conversation can quickly correct them.
Misaligned expectations of a product backlog lead to difficult in declaring "backlog bankruptcy" and the product backlog becomes really hard to maintain.
I agree with "things we might do" as a new name for product backlog, if we can develop a shorter version :)
I'm with you on the idea that a backlog is a list of ideas. But! In scrum, backlogs get refined periodically. New ideas come. Bad ideas get culled. Ideas get discussed and they move up the ladder, get more refined, get acceptance criteria added and ultimately a decision is made: does this add value to the product/customer/etc. Yes, backlogs can be a dumping ground where ideas go to die. But only when that refinement step is ignored.
This has been annoying me for years as well. A backlog is a list of things that should have been done by now but have not. A plan or roadmap is a statement of what should be done in the future. I never understood how this term became currency when there were plenty of better, existing ones.
The argument seems to hinge on the idea of backlogs being work that must be done, but that seems weak.
First, not all of the definitions explicitly include the concept of "must". Of the 5 definitions, only ChatGPT's ("need to be") and Cambridge's ("must do now") include the idea of "need" or "must". The argument that a backlog is work that must be done doesn't seem to hold up when 3/5 of the definitions don't support it.
I also think the idea of "need" or "must" is different in an agile context. A hallmark of agility is responding to a changing environment. At a given point in time, the backlog represents the set of work that people believe "needs to be" done or "must be" completed. However, by doing the work and collaborating with stakeholders, we'll find things that must be done that we didn't think of or learn that something we felt was needed isn't. Just because we believe something must be done today doesn't mean we'll continue to hold that belief tomorrow once we see something that changes our minds.
If something won't be done or doesn't represent something someone thinks is necessary, there's no reason to put it on the backlog. Work that is far beyond the current vision for the product, for example, doesn't need to appear as an idea or option.
I see it differently. Each of the five definitions IMO communicates an expectation that the work will be done. And that is exactly how many clients will interpret the product backlog. While it would be much better, for expectation management and to prevent disappointment and endless discussion, to communicate the intent with different terminology.
This feels like an experience thing. I've never met anyone who understood that there was a commitment to finish everything in a backlog. This is especially true after explaining the agile perspective on vision, emergent work, and built-in change management/control, rather than a comprehensive requirements specification.
The terminology around backlogs is already well-entrenched. I struggle with the idea of new terminology without a better understanding of the category of people who have incorrect expectations and whether a conversation can quickly correct them.
Misaligned expectations of a product backlog lead to difficult in declaring "backlog bankruptcy" and the product backlog becomes really hard to maintain.
I agree with "things we might do" as a new name for product backlog, if we can develop a shorter version :)
I'm with you on the idea that a backlog is a list of ideas. But! In scrum, backlogs get refined periodically. New ideas come. Bad ideas get culled. Ideas get discussed and they move up the ladder, get more refined, get acceptance criteria added and ultimately a decision is made: does this add value to the product/customer/etc. Yes, backlogs can be a dumping ground where ideas go to die. But only when that refinement step is ignored.