28 Product Backlog Anti pattern を書いてみた



28 Product Backlog , Kaizen(Refinement) Anti Pattern

一般的な アンチ (General Anti)

1. Prioritization by proxy: A single stakeholder or a committee of stakeholder prioritizes the product backlog.

2. 100% in Advance: The scrum team creates a product backlog covering the complete project or product upfront because the scope of the release is limited. 

3. Over-sized: The product backlog contains more items than the scrum team can deliver within three to four sprints.

4. Outdated issues: The product backlog contains items that haven’t been touched for six to eight weeks or more.

5. Everything is estimated: All user stories of the product backlog are detailed and estimated.

6. Component-based items: The product backlog items are sliced horizontally based on components instead of vertically based on end-to-end features.

7. Missing acceptance criteria: There are user stories in the product backlog without acceptance criteria.

8. No more than a title: The product backlog contains user stories that comprise of little more than a title.

9. Issues too detailed: There are user stories with an extensive list of acceptance criteria.

10. Neither themes nor epics: The product backlog is not structured by themes or epics.

11. No research: The product backlog contains few to no spikes.

ポートフォリオ、ロードマップ (Portfolio and Product Roadmap Level)

1. Roadmap? The product backlog is not reflecting the roadmap.

2. Annual roadmaps: The organization’s portfolio plan, as well as the release plan or product roadmap, are created once a year in advance.

3. Roadmaps kept secret: The portfolio planning and the release plan or product roadmap are not visible to everybody.

4. China in your hands: The portfolio planning and the release plan or the product roadmap are not considered achievable and believable.

プロダクトオーナー (the Product Owner)

1. Storage for ideas: The product owner is using the product backlog as a repository of ideas and requirements.

2. Part-time PO: The product owner is not working daily on the product backlog.

3. Copy & paste PO: The product owner creates user stories by breaking down requirement documents received from stakeholders into smaller chunks.

4. Dominant PO: The product owner creates user stories by providing not just the ‘why’ but also the ‘how’, and the ‘what’.

5. INVEST? The product owner is not applying the INVEST principle by Bill Wake to user stories.

6. Issues too detailed: The product owner invests too much time upfront in user stories making them too detailed.

7. What team? The product owner is not involving the entire scrum team in the refinement process and instead is relying on just the “lead engineer”

8. ‘I know it all’ PO: The product owner does not involve stakeholders or subject matter experts in the refinement process.

開発視点(the Development Team)

1. Submissive team: The development team submissively follows the demands of the product owner.

2. What technical debt? The development team is not demanding adequate resources to tackle technical debt and bugs.

3. No slack: The development team is not demanding 20% slack time from the product owner.

スクラム視点(the Scrum Team)

1. No time for refinement: The team does not have enough refinement sessions, resulting in a low-quality backlog.

2. Too much refinement: The team has too many refinement sessions, resulting in a too detailed backlog.

3. No DoR: The scrum team has not created a ‘definition of ready’ that product backlog items need to match before becoming selectable for a sprint.


* Productbacklog anti pattern