Loading ...
Sorry, an error occurred while loading the content.

Release Planning / Grooming Approaches

Expand Messages
  • Carey, Ben
    I wanted to see what type of commitment that different teams are putting towards Release Planning and Backlog grooming. Any lessons-learned are also
    Message 1 of 4 , May 19, 2007
    • 0 Attachment
      Release Planning / Grooming Approaches

      I wanted to see what type of commitment that different teams are putting towards Release Planning and Backlog grooming. Any lessons-learned are also appreciated around these items. I know this varies drastically based on your situation, but Im interested in hearing how others are approaching these items.

      A few questions regarding these

      1.      How large do you keep your Product Backlog? (e.g. everything possible, everything for the release, next x months based on capacity, up to the next internal release, etc.)

      2.      Who is involved in providing estimates for the Product Backlog? (the team, developers only, other subsets, etc.)

      3.      How are you doing Product Backlog grooming? (at the end of each Sprint, all the time, regular meetings, etc.)

      4.      Are you expanding or elaborating on Backlog items before they are brought into the Sprint Planning meetings?

      Thanks in advance!

      -Ben

    • Henrik Kniberg
      ... It grows and shrinks in cycles. Basically the PO (product owner) and other stakeholders keep adding to it over time until the PO realizes (thanks to
      Message 2 of 4 , May 19, 2007
      • 0 Attachment
        On 5/20/07, Carey, Ben <ben.carey@...> wrote:
        > 1. How large do you keep your Product Backlog?

        It grows and shrinks in cycles. Basically the PO (product owner) and
        other stakeholders keep adding to it over time until the PO realizes
        (thanks to velocity tracking) that most of the stuff will never get
        done. So he chops off the bottom 80% of the product backlog and moves
        it to a separate "nice to have someday" list. That list is then
        promptly forgotten and never opened again :o)

        Then the cycle starts over as more items starts creeping into the
        product backlog again...

        Normally the bloating product backlog is not really a problem since we
        only look ahead a few sprints at a time. Any backlog items beyond that
        are ignored.

        > 2. Who is involved in providing estimates for the Product Backlog?
        > (the team, developers only, other subsets, etc.)

        During sprint planning meetings, the whole team (the PO is there but
        does not estimate). Those are the "official" estimates, the ones that
        count towards velocity and such.

        Outside of sprint planning meetings, estimates are usually provided by
        a subset of the team, i.e. whoever the PO can get a hold of at the
        moment. We call these pre-estimates, since they will be redone during
        the sprint planning meeting. The PO is allowed to ask the team for any
        estimate at any time, although usually it doesn't happen more than
        once or twice per week.

        The estimates for the backlog items in the current sprint are updated
        by the team every day before the daily scrum. More specifically, the
        pair working on a backlog item update the time estimate for that item
        every day before reporting at the daily scrum.

        > 3. How are you doing Product Backlog grooming? (
        > at the end of each Sprint, all the time, regular meetings, etc.)

        The most important grooming is done a day or two before the sprint
        end. Usually ScrumMaster helps PO clarify all high-priority items and
        clean out junk from the product backlog (for example completed
        stories), so that the top-priority section of the product backlog is
        nice and clean for the sprint planning meeting.

        I've found it hard to get POs to "take 100% ownership" of the product
        backlog, often a PO just adds new stuff to the backlog and
        reprioritizes, but doesn't maintain and refactor the product backlog
        itself until the ScrumMaster helps him.

        So during the sprint the PO adds and modifies, but doesn't clean. Just
        before sprint end, ScrumMaster helps PO clean up the product backlog.

        > 4. Are you expanding or elaborating on Backlog items
        > before they are brought into the Sprint Planning meetings?

        Usually not. Sometimes a PO writes a seperate spec for a backlog item
        if he knows (or believes he knows) the details. However that spec is
        never treated as final, it is just input.

        The ScrumMaster (or other people in the team) usually try to help the
        PO ensure that the top-priority items are reasonably well broken down
        before the sprint planning meeting, to save time.

        /Henrik

        --
        Henrik Kniberg
        http://www.crisp.se
        +46 (0)70 492 5284
      • dnicolet99
        The way we do it is the Product Backlog contains everything. There are also a Release Backlog and a Sprint Backlog, which contain what the titles suggest. Dave
        Message 3 of 4 , May 22, 2007
        • 0 Attachment
          The way we do it is the Product Backlog contains everything. There are
          also a Release Backlog and a Sprint Backlog, which contain what the
          titles suggest.

          Dave


          --- In scrumdevelopment@yahoogroups.com, "Carey, Ben" <ben.carey@...>
          wrote:
          >
          > I wanted to see what type of commitment that different teams are putting
          > towards Release Planning and Backlog grooming. Any lessons-learned are
          > also appreciated around these items. I know this varies drastically
          > based on your situation, but I'm interested in hearing how others are
          > approaching these items.
          >
          > A few questions regarding these...
          >
          > 1. How large do you keep your Product Backlog? (e.g. everything
          > possible, everything for the release, next x months based on capacity,
          > up to the next internal release, etc.)
          > 2. Who is involved in providing estimates for the Product Backlog?
          > (the team, developers only, other subsets, etc.)
          > 3. How are you doing Product Backlog grooming? (at the end of each
          > Sprint, all the time, regular meetings, etc.)
          > 4. Are you expanding or elaborating on Backlog items before they
          > are brought into the Sprint Planning meetings?
          >
          > Thanks in advance!
          >
          > -Ben
          >
        • Jeff Martin
          Every feature idea, even the crazy ones, go in the product backlog. Then we have a release backlog for the current release and maybe for the next release. And
          Message 4 of 4 , May 22, 2007
          • 0 Attachment

            Every feature idea, even the crazy ones, go in the product backlog.  Then we have a release backlog for the current release and maybe for the next release.  And of course the current sprint backlog (just to throw a little gasoline on the Language thread fire, we use the term iteration not sprint, it just has a clearer meaning to those not familiar with agile).

            Estimates are generally a team thing, if someone is just putting something in the product backlog for future release, we just use a rough story point estimate or even leave it as 0, to be addressed when we get closer to it.

             

            I usually groom the backlog a bit as we approach a release point.  Sometimes we get duplicates, usually due to wording differences, so I go through and make sure to clear those out.  Sometimes the PO will remove an item because another feature we did provided the same information or made it obsolete.  We haven’t ever removed something from the product backlog because of scope or time constraints.  We have from *release* backlog, but it just goes back into the product backlog.  I’m sure eventually we will, but we are an in-house shop, so our time constraints are a little different from someone on a 6 month contract.  The PO jokes that the project we’re working on now will be the last project we work on here, because pretty much everything he envisions revolves around this project.

             

            We do elaborate a little on backlog items before iteration planning.  Often the stories that go into the product backlog are more epics than stories.  We’ll sit down and break them down a bit more before we start planning the iteration.

             


            From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Carey, Ben
            Sent: Saturday, May 19, 2007 5:16 PM
            To: scrumdevelopment@yahoogroups.com
            Subject: [scrumdevelopment] Release Planning / Grooming Approaches

             

            I wanted to see what type of commitment that different teams are putting towards Release Planning and Backlog grooming. Any lessons-learned are also appreciated around these items. I know this varies drastically based on your situation, but I’m interested in hearing how others are approaching these items.

            A few questions regarding these…

            1.      How large do you keep your Product Backlog? (e.g. everything possible, everything for the release, next x months based on capacity, up to the next internal release, etc.)

            2.      Who is involved in providing estimates for the Product Backlog? (the team, developers only, other subsets, etc.)

            3.      How are you doing Product Backlog grooming? (at the end of each Sprint, all the time, regular meetings, etc.)

            4.      Are you expanding or elaborating on Backlog items before they are brought into the Sprint Planning meetings?

            Thanks in advance!

            -Ben

          Your message has been successfully submitted and would be delivered to recipients shortly.