The product backlog: your ultimate to-do list

グルーミング (手入れ) が行き届き、整理され、オープンな状態にあるものを指します。

Dan Radigan Dan Radigan

アジャイルバックログの優先順位が適切に設定されていると、リリースやイテレーション計画が容易になるだけではなく、顧客が知ることのない内部作業を含むあらゆるチーム活動を全体が把握できます。利害関係者や他のチームは予測を立てやすくなり (特に追加作業を依頼するとき)、エンジニアリング期間を固定できます。


A product backlog is a prioritized list of work for the development team that is derived from the roadmap and its requirements. The most important items are shown at the top of the product backlog so the team knows what to deliver first. The development team doesn't work through the backlog at the product owner's pace and the product owner isn't pushing work to the development team. Instead, the development team pulls work from the product backlog as there is capacity for it, either continually (kanban) or by iteration (scrum).  

Pro Tip:

Keep everything in one issue tracker–don’t use multiple systems to track bugs, requirements, and engineering work items. If it's work for the development team, keep it in a single backlog.

2 つの「R」から始める

A team's roadmap and requirements provide the foundation for the product backlog. Roadmap initiatives break down into several epics, and each epic will have several requirements and user stories. Let's take a look at the roadmap for a ficticious product called Teams in Space.

Agile roadmap | Atlassian agile coach

Since the Teams in Space website is the first initiative in the roadmap, we'll want to break down that initiative into epics (shown here in green, blue, and teal) and user stories for each of those epics. 

Agile initiatives and epics | Atlassian agile coach

The product owner then organizes each of the user stories into a single list for the development team. The product owner may choose to deliver a complete epic first (left). Or, it may be more important to the program to test booking a discounted flight which requires stories from several epics (right). See both examples below. 

Agile epics and stories | Atlassian agile coach


  • 顧客の優先事項
  • フィードバック取得の緊急度
  • 実装の相対的な難易度
  • 作業項目間の共生関係 (A を先に完了すると B が容易になるなど)



Once the product backlog is built, it's important to regularly maintain it to keep pace with the program. Product owners should review the backlog before each iteration planning meeting to ensure prioritization is correct and feedback from the last iteration has been incorporated. Regular review of the backlog is often called "backlog grooming" in agile circles(some use the term backlog refinement).

バックログが大きくなったら、プロダクトオーナーがバックログを短期目標と長期目標にグループ分けします。グループ分けをする前に、短期目標を完全に具体化する必要があります。つまり、完全なユーザーストーリーを作成し、設計および開発チームとのコラボレーション体制を整え、開発チームから見積もりを受け取ります。長期目標には少し曖昧さが残ってもかまいませんが、優先順位を設定するために開発チームから大体の見積もりを受け取っておくとよいでしょう。重要なのは「大体の」という点です。 チームが長期目標を完全に把握して取り掛かる時点で、見積もりに変更が生じるからです。


Pro Tip:

Once the backlog grows beyond the team's long term capacity, it's okay to close issues the team will never get to. Flag those issues with a specific resolution like “out of scope” in the team's issue tracker to use for research later. 


  • プロダクトオーナーはプロジェクト開始時にバックログの優先順位を設定するが、開発者や利害関係者からのフィードバックを受けても調整を行わない。
  • バックログの項目が顧客向けのものに限られている。
  • バックログはローカル文書として保存され、共有されることが少ないため、関係者が更新を受け取ることがない。




The product backlog also serves as the foundation for iteration planning. All work items should be included in the backlog: user stories, bugs, design changes, technical debt, customer requests, action items from the retrospective, etc. This ensures everyone's work items are included in the overall discussion for each iteration. Team members can then make trade-offs with the product owner before starting an iteration with complete knowledge of everything that needs to be done.

Pro Tip:

Product owners dictate the priority of work items in the backlog, while the development team dictates the velocity through the backlog. This can be a tenuous relationship for new product owners who want to "push" work to the team. Learn more in our article about work-in-progress limits and flow. 

Sprint reviews