제품 백로그 - 설명 및 만드는 방법

우선 순위가 잘 지정된 애자일 백로그는 릴리스 및 반복 계획을 더 쉽게 만들어 줄 뿐만 아니라 고객이 알아차리지 못할 만한 내부 작업을 포함하여 팀이 시간을 할애하려는 모든 것을 알려줍니다. 특히 추가 작업을 가져올 때 이해 관계자 및 다른 팀과 기대치를 설정하고 엔지니어링 시간을 고정 자산으로 만드는 데 도움이 됩니다.

제품 백로그는 제품 로드맵 및 그 요구 사항에서 파생된 개발 팀에서 수행할 우선 순위가 지정된 작업 목록입니다. 가장 중요한 항목은 제품 백로그 상단에 표시되므로 팀은 무엇을 가장 먼저 제공해야 하는지 파악할 수 있습니다. 개발 팀은 제품 소유자의 속도에 맞춰 백로그 작업을 하지 않으며 제품 소유자는 개발 팀에 작업을 푸시하지 않습니다. 대신 작업 수용량이 있으므로 개발 팀은 지속적으로(칸반) 또는 반복을 통해(스크럼) 제품 백로그에서 작업을 가져옵니다.

Try Jira Scrum boards

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.

A well-managed product backlog can bring numerous benefits to a development team. Some of the key benefits include:

• Improved prioritization: A product backlog helps to ensure that the most critical tasks are being worked on first.
• Increased efficiency: By prioritizing tasks based on customer feedback and business objectives, teams can ensure they work on the most valuable tasks.
• Better communication: A product backlog ensures everyone is aligned and working towards the same goals.
• Reduced waste: By prioritizing tasks based on customer feedback and business objectives, teams can reduce waste and ensure that they are not working on tasks that are not valuable.
• Improved customer satisfaction: By prioritizing tasks based on customer feedback, teams can ensure they deliver customers' desired features and functionality.

Overall, a well-managed product backlog is essential for agile product development. It ensures that teams are working on the most valuable tasks and that everyone is aligned and working towards the same goals.

팀의 로드맵(Roadmap)과 요구 사항(Requirement)은 제품 백로그의 토대를 마련해 줍니다. 로드맵 이니셔티브는 여러 에픽으로 나뉘며 각 에픽에는 다양한 요구 사항과 사용자 스토리가 있습니다. 스페이스의 팀이라는 가상의 제품에 대한 로드맵을 살펴보겠습니다.

로드맵의 첫 번째 이니셔티브는 스페이스의 팀 웹사이트이므로 해당 이니셔티브를 에픽(녹색, 파란색 및 청록색으로 표시) 및 각 에픽의 사용자 스토리로 나눠야 합니다.

그런 다음 제품 소유자는 각 사용자 스토리를 개발 팀의 단일 목록으로 구성합니다. 제품 소유자는 완료한 에픽을 먼저 제공하도록 선택할 수도 있으며(왼쪽), 또는 여러 에픽의 스토리가 필요한 할인 항공편 예약을 테스트하는 것이 프로그램에 더 중요할 수도 있습니다(오른쪽). 아래의 두 가지 예를 모두 살펴보세요.

제품 소유자의 우선 순위에 영향을 줄 수 있는 요인은 무엇입니까?

• 고객 우선 순위
• 피드백의 긴급성
• 구현의 상대적인 어려움
• 작업 항목 간의 공생 관계(예: A를 먼저 하면 B가 더 쉬움)

제품 소유자는 백로그의 우선 순위를 정하는 임무를 맡지만, 이러한 작업은 외부와 단절된 상태에서 이루어지지는 않습니다. 효과적인 제품 소유자는 모두의 워크로드와 제품 제공을 최적화하기 위해 고객, 디자이너 및 개발 팀의 의견과 피드백을 구합니다.

제품 백로그를 만들면 프로그램과의 속도를 맞추기 위해 정기적으로 유지 관리하는 것이 중요합니다. 제품 소유자는 각 반복 계획 미팅을 진행하기 전에 백로그를 검토하여 우선 순위가 올바르고 마지막 반복의 피드백이 반영되었는지 확인해야 합니다. 애자일 서클에서는 백로그에 대한 정기적인 검토를 "백로그 그루밍"이라고 하는 경우가 많습니다(일부는 백로그 세분화라는 용어를 사용함).

백로그가 커지면 제품 소유자는 백로그를 단기적 및 장기적 항목으로 그룹화해야 합니다. 단기적 항목은 단기적인 것으로 분류되기 전에 완전히 구체화해야 합니다. 즉, 완전한 사용자 스토리를 작성하고 디자인 및 개발 팀과의 공동 작업을 분류하고 개발 팀에서 추정치를 계산해야 합니다. 장기적 항목은 약간 막연할 수 있지만 우선 순위를 정하는 데 도움이 되도록 개발 팀으로부터 대략적인 추정치를 받는 것이 좋습니다. 여기서 핵심 단어는 "대략적"입니다. 팀이 장기적 항목을 완전히 파악하고 작업을 시작하면 추정치가 변경될 것입니다.

백로그는 제품 소유자와 개발 팀 간의 연결고리 역할을 합니다. 제품 소유자는 고객 피드백, 추정치 조정 및 새로운 요구 사항으로 인해 언제든지 백로그에서 작업의 우선 순위를 다시 지정할 수 있습니다. 하지만 작업이 진행되면 변경 사항은 개발 팀을 방해하고 집중력, 흐름 및 사기에 영향을 미치므로 변경 사항을 최소한으로 유지하세요.

유능한 제품 소유자는 프로그램의 제품 백로그를 철저하게 그루밍하여 프로젝트의 작업 항목에 대해 신뢰할 수 있고 공유 가능한 개요를 만듭니다.

이해 관계자는 우선 순위에 의문을 제기할 것이며, 이는 좋은 현상입니다. 중요한 것에 대한 논의를 조성하면 모두가 같은 우선 순위를 가지게 됩니다. 이러한 논의는 모두가 프로그램에 대해 같은 사고 방식을 공유하도록 그룹 우선 순위를 지정하는 문화를 조성합니다.

제품 백로그는 반복 계획의 기반으로도 사용됩니다. 사용자 스토리, 버그, 디자인 변경, 기술적 부채, 고객 요청, 회고의 작업 항목 등 모든 작업 항목이 백로그에 포함되어야 합니다. 이렇게 하면 팀은 각 반복에 대한 전체 논의에 모두의 작업 항목이 포함되도록 보장할 수 있습니다. 그런 다음 팀원은 해야 할 모든 작업에 대한 완전한 지식을 갖추고 반복을 시작하기 전에 제품 소유자와 절충을 이룰 수 있습니다.

Effective communication is critical when creating a product backlog. The product owner should work closely with the development team to ensure everyone understands the product backlog and the priorities. The product owner should also communicate with other teams, such as sales and marketing, to ensure everyone is aligned and working towards the same goals. 

Regular meetings and updates ensure everyone is on the same page and that the product backlog is effectively managed.

Still need guidance? Check out the free product backlog template from Jira.

Backlog prioritization is essential for ensuring the development team focuses on tasks that deliver maximum impact. Here’s how to approach it:

Various backlog prioritization techniques, such as MoSCoW and weighted scoring, can help teams manage and order tasks effectively. The prioritization process involves regularly revising and realigning goals to adapt to a dynamic business environment.

• Identify features or fixes that will have the highest value for your users.
• Use customer feedback, surveys, or analytics to pinpoint priorities.

• Prioritize items that will generate actionable insights for the team or stakeholders.
• For example, testing a new feature early can save time and resources later.

• Balance your backlog by including quick wins and more complex, long-term projects.
• Weigh the effort-to-impact ratio to ensure resources are spent wisely.

• Identify tasks that must be completed before others can proceed.
• Streamline workflows by handling foundational work first.

Reliable tools that support backlog prioritization can streamline product development and enhance efficiency. While the product owner leads prioritization, involving the development team, designers, and stakeholders fosters a shared understanding of priorities. Regular discussions ensure alignment and improve decision-making.

Pro tip: Use prioritization frameworks like MoSCoW (Must-have, Should-have, Could-have, and Won’t-have) or weighted scoring to make objective, data-driven decisions. Teams can implement their own unique prioritization frameworks using the flexible prioritization feature in Jira Product Discovery.

Once the product backlog is built, it’s crucial to maintain it to keep pace with the program regularly. 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 backlog review, often called product backlog refinement in agile circles, ensures that tasks are aligned with stakeholder insights and prepares the team for the upcoming sprint (some use the term backlog refinement).

Once the backlog gets larger, product owners need to group the backlog into near-term and long-term items. Near-term items need to be fully fleshed out before they are labeled as such. This means complete user stories have been drawn up, collaboration with design and development has been sorted out, and estimates from development have been made. 

Longer-term items can remain vague, though it’s a good idea to get a rough estimate from the development team to help prioritize them. The key word here is “rough,” as estimates will change once the team fully understands and begins work on them.

The backlog serves as the connection between the product owner and the development team. The product owner can re-prioritize work in the backlog based on customer feedback, refining estimates, and new requirements. However, once work is in progress, changes should be kept to a minimum, as they disrupt the development team and affect focus, flow, and morale.

Pro tip: Once the backlog grows beyond the team’s long-term capacity, closing issues the team will never get to is okay. For future research, flag those issues with a specific resolution, like “out of scope,” in the team’s issue tracker.

Anti-patterns to watch for

• The product owner prioritizes the backlog at the start of the project but doesn’t adjust it as feedback rolls in from developers and stakeholders.
• The team limits items on the backlog to those that are customer-facing.
• The backlog is kept as a document stored locally and shared infrequently, preventing interested parties from getting updates.

Savvy product owners rigorously groom their program’s product backlog to create a reliable and sharable outline of the project's work items.

Stakeholders will challenge priorities, and that’s good. Fostering discussion around what’s important gets everyone’s priorities in sync. These discussions foster a culture of group prioritization, ensuring everyone shares the same mindset about the program.

A well-prioritized agile backlog clarifies what the team intends to spend time on, highlighting visible and internal tasks. 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 its velocity. This can be a tenuous relationship for new product owners who want to “push” work to the team. This article explains work-in-progress limits and flow.