Product backlog




Scrum Product Backlog

This video is part of our 19-part Scrum Foundations video series. Click here to watch the rest of the series for free.

The agile product backlog in Scrum is a prioritized features list, containing short descriptions of all functionality desired in the product. When applying Scrum, it’s not necessary to start a project with a lengthy, upfront effort to document all requirements. Typically, a Scrum team and its product owner begin by writing down everything they can think of for agile backlog prioritization. This agile product backlog is almost always more than enough for a first sprint. The Scrum product backlog is then allowed to grow and change as more is learned about the product and its customers.

A typical Scrum backlog comprises the following different types of items:

  1. Features
  2. Bugs
  3. Technical work
  4. Knowledge acquisition

By far, the predominant way for a Scrum team to express features on the agile product backlog is in the form of user stories, which are short, simple descriptions of the desired functionality told from perspective of the user. An example would be, «As a shopper, I can review the items in my shopping cart before checking out so that I can see what I’ve already selected.»

Because there’s really no difference between a bug and a new feature — each describes something different that a user wants — bugs are also put on the Scrum product backlog.

Technical work and knowledge acquisition activities also belong on the agile backlog. An example of technical work would be, «Upgrade all developers’ workstations to Windows 7.» An example of knowledge acquisition could be a Scrum backlog item about researching various JavaScript libraries and making a selection.

The product owner shows up at the sprint planning meeting with the prioritized agile product backlog and describes the top items to the team. The team then determines which items they can complete during the coming sprint. The team then moves items from the product backlog to the sprint backlog. In doing so, they expand each Scrum product backlog item into one or more sprint backlog tasks so they can more effectively share work during the sprint.

Conceptually, the team starts at the top of the prioritized Scrum backlog and draws a line after the lowest of the high-priority items they feel they can complete. In practice, it’s not unusual to see a team select, for example, the top five items and then two items from lower on the list that are associated with the initial five.

Scrum Foundations Video Series

All the foundational knowledge of Scrum including: the framework, values, different roles, meetings, backlogs, and improving efficiency & quality.

Product Backlog ตามตำรา

Get Rid of Big Requirement Upfront with Product Backlog

Product Backlog คือ?

Product Backlog ใน Scrum คือลิสต์ของงานใน Product นั้น (เท่านั้น) ที่ได้รับการจัดลำดับความสำคัญโดยในงานแต่ละงานจะมีคำอธิบายสั้นๆถึงความหมายและความต้องการของมัน มองง่ายๆคือ Product Backlog เป็นแนวทางการเขียน Requirement Specification ในรูปแบบใหม่ที่สั้น ง่าย เร็ว ยืดหยุ่น และคล่องตัวกว่าเดิม

อีกมุมมองหนึ่ง Product Backlog จะอายุยืนกว่า Requirement Specification มาก (อย่างที่รู้กันว่าไม่ค่อยมีใครอ่านเอกสารหนาเตอะแบบนี้หรอก) เพราะ Scrum Team จะทำงานโดยอ้างอิงกับ Product Backlog โดยตลอดในแทบทุกกิจกรรม เช่น Spring Planning, และ Product Backlog Refinement (Grooming) ทำให้การปรับปรุง เปลี่ยนแปลง และแก้ไข Product Backlog เป็นเรื่องปกติที่จำเป็นต้องทำนั่นเอง

Product Backlog Item

เราต้องทำความเข้าใจเพิ่มเติมอีกนิดว่า Product Backlog เป็นแค่แฟ้มโดยของที่อยู่ในแฟ้มนั้นเราเรียกว่า Product Backlog Item ซึ่งมีอยู่หลากหลายรูปแบบ ดังนี้

  1. Features — โดยทั่วไป Features ที่อยู่ใน Product Backlog จะเขียนอยู่ในรูปแบบของ User Story
  2. Bugs — ก็ไม่ต่างกับ Features ครับ Bugs เป็นสิ่งที่เกี่ยวข้องโดยตรงกับ Product ในแง่ของคุณภาพ มันเป็นงานที่ทีมต้องทำ ดังนั้นมันจึงอยู่ใน Product Backlog ได้เช่นกัน
  3. Technical work — เป็นงานด้านเทคนิคที่จำเป็นต้องทำแต่ไม่เกี่ยวของโดยตรงกับความต้องการของผู้ใช้ เช่น Install VM, Update patch, Create build script และอื่นๆ
  4. Research / Knowledge acquisition — เมื่อ Scrum Team อยู่ในสถานการณ์ที่ต้องการความรู้หรือข้อมูลเพิ่มเติมเพื่อตัดสินใจในด้านเทคนิค เราจะเขียนงานประเภทนี้ไว้ใน Product Backlog ในรูปแบบของ Spike ด้วย เช่น Research on AngularJS and jQuery เป็นต้น
Healthy Product Backlog

Product Owner และ Scrum Team ทุกคนมีส่วนรับผิดชอบในการสร้างและดูแล Product Backlog ให้อยู่ในสภาพที่พร้อมใช้งานอยู่เสมอ … คำว่าพร้อมใช้งานคือ

  1. Product Backlog Item ได้รับการจัดเรียงลำดับความสำคัญจากมากสุด (บนสุด) ไปน้อย(ล่าง) … ไม่จำเป็นว่า User Story ต้องอยู่บนสุดเสมอไป มันอาจจะเป็น Bugs, หรือ Technical work ก็ได้ เราไม่จำเป็นต้องเรียงลำดับความสำคัญของงานให้ครบทุกชิ้นสิ่งสำคัญคือเราต้องเรียงลำดับงานให้ชัดเจนเผื่อไว้ซัก 1–2 Sprint ส่วนที่เหลือกองๆไว้ก็ได้ … Priority มันเปลี่ยนได้ตลอดเวลา
  2. Product Backlog Item ที่อยู่ส่วนบนๆต้องมีข้อมูลเรื่องความหมายและผลลัพธ์ที่ต้องการระบุไว้อย่างชัดเจนในระดับที่ Scrum Team มีความมั่นใจในการทำงานเหล่านั้น ถ้าเป็น User Story ก็ควรต้องได้ตามกฎ INVEST … เวทีที่ Scrum Team ใช้ในการพูดคุยในรายละเอียดของ Product Backlog Item นี้เรียกว่า Product Backlog Refinement (Grooming)
  3. Product Backlog Item ที่อยู่ส่วนบนๆควรต้องได้รับการประเมินขนาด (Estimate) โดย Scrum Team แล้ว จะด้วยหลักการ Story Point หรืออะไรก็ตามแต่ สิ่งนี้จะถูกใช้เปรียบเทียบกับ Average Velocity ระหว่างการทำ Sprint Planning
“XXX” Backlog

ถ้าการจัดงานทั้งหมดมารวมกันที่ Product Backlog ที่เดียวมันวุ่นวายและปนเปกันมากเกินไป เรามีทางออก … เพราะคำว่า “Backlog” แปลว่า “งานที่ยังไม่ได้ทำ” ทำให้หลายๆครั้งเราสามารถเลือกใช้คำว่า Backlog กับสิ่งอื่นๆได้เช่นกัน ที่นิยมกันมาก เช่น Bug Backlog, Technical Backlog และ Happiness Backlog (อันนี้ผมคิดเอง ฮ่าๆ)

ในระหว่างการทำ Sprint Planning เราสามารถกำหนดสัดส่วนการทำงานให้เหมาะสมกับทุกๆ Backlog ได้ ประมาณนี้

  • Product Backlog = 50%
  • Bug Backlog = 20%
  • Technical Backlog = 20%
  • ว่างๆไว้ = 10% ☺

ป.ล. ที่ผมเขียนมานั้นเป็นไปตามตำราบวกกับความรู้ส่วนตัวที่มี … แต่ … หลังๆมานี้ผมเบื่อคำว่า Product Backlog ตามตำรามากเลย เพราะอะไรไว้เล่าให้ฟังครับ

ผมเขียนบทความนี้เพราะอยากเปลี่ยนแปลงสิ่งที่เป็นอยู่ในอุตสาหกรรมการผลิตซอฟท์แวร์ให้ดีขึ้นตามความเชื่อและประสบการณ์ของผม ถ้าเพื่อนๆเชื่อในแนวทางเดียวกัน เรามาช่วยกันคนละไม้คนละมือทำให้สังคมของเราดีขึ้นครับ จะแชร์บทความนี้ผ่าน Social Network หรือจะแบ่งปันเรื่องราวนี้ให้คนที่นั่งข้างๆฟังบ้างก็ได้

The Future Has Arrived — It’s Just Not Evenly Distributed Yet, William Gibson

อนาคตอยู่ตรงนี้แล้ว เรามีหน้าที่ต้องถ่ายทอดมันออกไปให้คนอื่นได้สัมผัสสิ่งดีๆร่วมกันครับ

The product backlog: your ultimate to-do list

A healthy product backlog is much like a healthy human: groomed, organized, and living in the open.

Browse topics

A well-prioritized agile backlog not only makes release and iteration planning easier, it broadcasts all the things your team intends to spend time on—including internal work that the customer will never notice. This helps set expectations with stakeholders and other teams, especially when they bring additional work to you, and makes engineering time a fixed asset.

What is a product backlog?

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).

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.

Start with the two «R»s

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.

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.

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.

What may influence a product owner’s prioritization?

  • Customer priority
  • Urgency of getting feedback
  • Relative implementation difficulty
  • Symbiotic relationships between work items (e.g. B is easier if we do A first)

While the product owner is tasked with prioritizing the backlog, it’s not done in a vacuum. Effective product owners seek input and feedback from customers, designers, and the development team to optimize everyone’s workload and the product delivery.

Keeping the backlog healthy

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).

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 a bit 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»: estimates will change once the team fully understands and begins work on those longer term items.

The backlog serves as the connection between the product owner and the development team. The product owner is free to re-prioritize work in the backlog at any time due to customer feedback, refining estimates, and new requirements. Once work is in progress, though, keep changes to a minimum as they disrupt the development team and affect focus, flow, and morale.

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.

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.

How do product backlogs keep the team agile?

Savvy product owners rigorously groom their program’s product backlog, making it a reliable and sharable outline of the work items for a project.

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 on the program.

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.

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.

Product Backlog Grooming Best Practices: What it is and Why it’s Critical

By Samer Fallouh

The new product development process can be messy and unwieldy if it’s not managed carefully. In agile projects, product backlog grooming is the key to making sure that projects stay on track.

In this post, we share what it is, best practices for effective backlog grooming meetings and how it makes for better (and easier) sprint planning.

WHAT IS PRODUCT BACKLOG GROOMING?

Backlog is defined as the full set of user stories not in the current sprint that defines the remainder of the project’s scope. Left unattended, the list of individual items on a product backlog can quickly become overwhelming to any development team.

When that happens, the status of individual user stories can become unclear, the team can lose focus on important tasks and they may have trouble estimating the time and resources needed to complete items, and the project completion date can slip.

Enter the product backlog grooming meeting, which is basically a meeting between the project manager and customer point of contact in which the participants break the backlog down into user stories and reprioritize them.

You may also hear it referred to as a product backlog refinement meeting or story time session, but whatever the terminology, the purpose is to discuss the current backlog list and offer suggestions for improving it, which may take the form of:

  • Writing new user stories, a process we outline in the post, Our Approach to Developing User Stories.
  • Refining and reprioritizing previously written user stories and breaking them down into smaller stories, if needed.
  • Redefining acceptance and testing criteria.
  • Reviewing time and personnel estimates for individual backlog items, utilizing what we’ve learned from completed sprints.
  • Adding new product features, then prioritizing and estimating them.
  • Looking more extensively into the total backlog to enable long-range technical and project planning.

Take special note of the last item: long-range technical and project planning. Many project managers limit grooming meetings to tasks related to the next sprint, but we believe that approach misses an opportunity to keep a project that’s in good shape running well in subsequent sprints. For example, the meeting can be useful in alerting product owners of possible challenges and obstacles down the road, keeping the team on track and ahead of schedule.

BACKLOG GROOMING BEST PRACTICES

Timing is Critical

At Dialexa, we normally hold the backlog grooming meeting 3–4 days after the start of a sprint (around a week before the next sprint in our typical two week sprints), and the meeting typically follows a demo of the prior sprint’s deliverables. As the project status is then fresh on participants’ minds, the client is familiar with recent project progress and gaps prior to discussing the backlog.

The meeting should leave the team feeling familiar with the product backlog and with a clear understanding of the goals for the next sprint. At the end of each sprint, we do a sprint planning meeting to verify there are no major changes to the backlog and decide the expected content for the next sprint. This allows the development team to start the next sprint with confidence.

Plan for Success

Implementing well-managed meetings will improve the overall speed and efficiency of the sprint planning meetings that follow, helping to boost commitment and product familiarity.

It’s important to clearly state expectations upfront for what needs to be accomplished during the meeting and have a set agenda. This puts everyone in the same mindset, saves valuable time and keeps the meeting flowing smoothly. Sometimes these recurring meetings can get tedious so a well-run meeting will make all the difference.

The goal here is for all attendees to leave the meeting with a clear understanding of what is left for project completion and the upcoming sprint goals.

Right Folks, Right Time

Attendees should include the project manager, the customer point of contact and key individual development team members, if required. A well organized backlog grooming meeting can save the time of valuable development resources.

Some companies limit customer participation, but at Dialexa, the customer is a part of the team and we teach them the dance that is an agile project. We have found that educating and partnering with our clients in a transparent way is key to reducing surprises and increasing understanding of all involved.

FINAL THOUGHT

There’s no question that backlog grooming meetings are a critical step in improving the speed and efficiency of your agile project, greatly reducing scope creep and increasing team grasp of project deliverables. Adhering to the best practices above can ensure that you get the most of backlog grooming meetings.

To learn more about how Dialexa solves problems check out our range of ebooks on strategy, transformation and product thinking: http://by.dialexa.com/resources

At Dialexa we start by asking “Do you know what your business will look like tomorrow?” Whether you have a plan, a problem or no idea, connect with us to explore the right answers for you.

Product Backlog VS Sprint Backlog difference In Agile Methodology

1. What is a Product Backlog

The product backlog is a priority list of user requirements, use cases to be done in order to create, maintain and sustain a product. Product Owner owns the product backlog,(s)he is the one who prioritize it based on the customers feedback or business value. For details about how to write user stories, template, examples and acceptance criteria are already covered in our previous blog

1.1. Characteristic of a Product Backlog

  • It is a very active document where all the wishlist and user requirements are gathered
  • Product owner makes sure that content of product backlog “user stories” are defined in detailed level
  • user story in product backlog should be enough in sizing to be fit in one sprint
  • All aspects like use case scenarios, condition of satisfaction aka acceptance criteria should be provided in each of the user stories
  • The product backlog acts as an input to the sprint backlog when comes to functionality
  • There are also bugs/issues, epic, user stories and themes are included in the product backlog
  • There are also bugs/issues, epic, user stories and themes are included in the product backlog
  • To put it short: The product backlog is the wish list for the product for the whole lifecycle. It defined with its detail nature what to be implemented.

1.2. Techniques Used To Maintain Product Backlog Effectively

1.2.1. DIVE

Product backlog items are prioritized in linearly ordered based upon DIVE criteria

  • Dependencies – keep it linear with fewer dependencies with other user stories, epic or themes. It’s OK to have horizontal dependencies.
  • Insure against risk (business and technical)
  • Business Value
  • Estimated Effort

1.2.2. DEEP

  • Detailed
  • Estimated
  • Emergent
  • Prioritized
  • Independent The user story should be self-contained, in a way that there is no inherent dependency on another user story.
  • Negotiable User stories, up until they are part of an iteration, can always be changed and rewritten.
  • Valuable A user story must deliver value to the end user.
  • Estimable You must always be able to estimate the size of a user story. Small User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty.
  • Testable The user story or its related description must provide the necessary information to make test development possible.

2. What is sprint backlog

There are also bugs/issues included in the sprint backlog for each sprint.

Sprint backlog is the subset of the product backlog. Each sprint, scrum team picks the user stories from product backlog on top of its stack, the number of user story picked by scrum team for a time box sprint is based on the average velocity of a scrum team. Product Onwer set the sprint’s goal for the team, scrum team pick the user stories from product backlog fulfilling those goals. Those user stories which moved to sprint is owned by scrum team, as the team is committed with the sprint backlog items during a sprint which is in timebox.