Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Scribd Logo
Upload

Welcome to Scribd!

  • 78 views

    Backlog Refinement Meeting

    Uploaded by

    rowdy rathore
    The document discusses product backlog refinement (PBR), which involves collaboratively clarifying product backlog items to prepare them for development. The purpose is to improve the backlog. Participants include the Scrum Master, product owner team, and development team. Backlog refinement typically occurs one to two sprints before development to add details without delays or stale information. Prerequisites include prioritizing items, identifying items not ready for the next sprint, and periodically reviewing epics and features. The team estimates items using poker planning and ensures stories have acceptance criteria and the right level of detail.

    Copyright:

    © All Rights Reserved
    Download as DOCX, PDF, TXT or read online from Scribd

    Backlog Refinement Meeting

    Uploaded by

    rowdy rathore
    78 views2 pages
    The document discusses product backlog refinement (PBR), which involves collaboratively clarifying product backlog items to prepare them for development. The purpose is to improve the backlog. Participants include the Scrum Master, product owner team, and development team. Backlog refinement typically occurs one to two sprints before development to add details without delays or stale information. Prerequisites include prioritizing items, identifying items not ready for the next sprint, and periodically reviewing epics and features. The team estimates items using poker planning and ensures stories have acceptance criteria and the right level of detail.

    Original Description:

    Backlog Refinement Meeting

    Copyright

    © © All Rights Reserved

    Available Formats

    DOCX, PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    The document discusses product backlog refinement (PBR), which involves collaboratively clarifying product backlog items to prepare them for development. The purpose is to improve the backlog. Participants include the Scrum Master, product owner team, and development team. Backlog refinement typically occurs one to two sprints before development to add details without delays or stale information. Prerequisites include prioritizing items, identifying items not ready for the next sprint, and periodically reviewing epics and features. The team estimates items using poker planning and ensures stories have acceptance criteria and the right level of detail.

    Copyright:

    © All Rights Reserved
    Download as DOCX, PDF, TXT or read online from Scribd
    Download as docx, pdf, or txt
    78 views2 pages

    Backlog Refinement Meeting

    Uploaded by

    rowdy rathore
    The document discusses product backlog refinement (PBR), which involves collaboratively clarifying product backlog items to prepare them for development. The purpose is to improve the backlog. Participants include the Scrum Master, product owner team, and development team. Backlog refinement typically occurs one to two sprints before development to add details without delays or stale information. Prerequisites include prioritizing items, identifying items not ready for the next sprint, and periodically reviewing epics and features. The team estimates items using poker planning and ensures stories have acceptance criteria and the right level of detail.

    Copyright:

    © All Rights Reserved
    Download as DOCX, PDF, TXT or read online from Scribd
    Download as docx, pdf, or txt
    of 2

    Product Backlog Refinement (Grooming)

    Purpose
    The purpose of PBR (Product backlog Refinement) is to make improvements to the product backlog.
    Though there is no official detailed in the Scrum Guide the activity of refining the Backlog is

    Who Participates?
    Backlog Refinement is collaborative effort involving

     Scrum Master keeps the session moving towards its intended goal
     Product Owner Team (Business Analyst) Clarifies the details of the backlog items
     Development Team define the work and effort necessary to fulfill the completion of agreed
    PBI. It is recommended to have at least one developer and one tester when refining the
    backlog, to ensure alternate view point of the system are present

    When do we Backlog Groom?


    Before development of user story in the current sprint (Iteration), generally sometime during the
    previous 1 or 2 sprints, the team sits down to discuss the upcoming work. Do not wait too late to
    add details, because the delay will slow the team down. Do not refine your stories too far in
    advance, because the details might get stale. Depending on the delivery rate of your teams you
    should be meeting once week to review the backlog.

    Prerequisites
    We need to ensure:

     Top order the PBI to reflect the greatest needs of management team and the product owner
    team.
     Candidates for grooming includes stories identified as not ready to complete with in the
    next sprint or will require multiple days of research.
     Periodically review epics, feature are other items on the management team road map

    Backlog
    The product backlog can address anything deemed valuable by the product owner team. For the
    purpose of sprint planning, when you use scrum as the delivery frame work, product backlog item
    must be small enough for the team to complete and accept during the sprint. Verify items are
    implemented to the satisfaction of the owner team. This is the time for the team to get clarification
    from any details regarding stories in the backlog. This will be the first time the team has seen the
    story to have a chance to clarify and get the PO to address any issues in the stories.

    Estimate -Poker Planning


    The team has whole should be using poker planning cards to estimate each of the stories. If there is
    a disagreement b/w why a story might be an 8 vs 3 then the individuals need to explain why they
    think it’s a 3 or an 8. Once they plain from their point of view then team can revote. The poker
    planning cards goes from a 0 to 100, the whole list of numbers is 0, 1, 2, 3, 5, 8, 13, 21, etc. Most
    teams only go up to an 8, since any story that is sized a 13 is usually a good candidate to broken up
    into a multiple user story.

    Inspect and question user stories


    Ensure stories have acceptance criteria. All stories require acceptance criteria. Without it, you
    cannot define the boundaries of the user story and confirm when a story is done and working as
    intended. Ensure acceptance criteria is testable. This is what your tester should be writing test
    against. Rewrite or breakup large user story. Ensure the user story format is consistent, meet INVEST
    criteria, and you write from a business not technical perspective. Know who the customer is. It may
    not be an end user. Rather, the story may be for something like a service for another team to
    consume.

    You might also like