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

21323Re: [scrumdevelopment] Sprint Review and Planning Process

Expand Messages
  • Nicholas Cancelliere
    May 2, 2007
      4 days of planning seems like a lot.  How long are your sprints?

      One quick comment about the estimates.  Instead of estimating duration have you ever tried to estimate size?  You might not be able to get everyone to agree to how long something takes but you can get everyone to agree to the size of the feature/story. 


      On 5/2/07, myoungtai <myoungtai@...> wrote:


      I am looking for a critique and some ideas regarding the sprint review
      and planning process.

      The development group I am in has been using Scrum for just under a
      year, and our implementation has evolved along with our understanding
      of and experience with Scrum. We have struggled with efficiency along
      the way, I think mostly attributable to coming up the learning curve.
      During the sprint, we are working pretty well now, but our review and
      planning process seems to still be poor. It feels like we fumble
      along and move really slow when meeting with the PO and other
      stakeholders. [Our PO is responsible for representing the requests
      from commercial sales customers, and a second manager represents the
      contracted development customers] In our developer meeting, we
      struggle to come up with task level (hour) estimates for stories where
      at most one person has familiarity with existing code - the others
      feel like they are just taking wild guesses at tasks and hours
      required for implementation.

      One of the developers on the team suggested the following process:

      Last week of Previous Sprint
      * Sales group and research group lobby the product owner and research
      manager for priority in the backlog [explain why their pet feature
      needs to be done now - potential sale, promised fix, contracted
      deliverable, ...]
      * PO and research manager combine their separate lists into one
      prioritized backlog

      Review/Planning Week
      Day One - Review
      * Scrum team holds sprint review, gets feedback from PO, researchers,
      internal users
      * Scrum team holds a retrospective to critique how the team worked
      together and find ways to improve

      Day Two - Planning Pt. 1
      * Scrum team meets with PO and research manager to estimate ideal
      developer days needed to implement stories on the backlog [we use
      planning poker to keep the discussion on topic and moving forward].
      * PO and other stakeholders have time to reprioritize list based on
      estimates and other inputs

      Day Three - Research Day
      * Scrum team subdivides into groups of 2-3 to investigate the task
      level details required to implement the stories in the backlog - ask
      PO questions, look at code, brainstorm general approach... Estimate
      as many stories as possible in one day. This is meant to get more
      eyes on each problem and hopefully come up with more reliable
      estimates since they are at a finer scale.

      Day Four - Planning Pt. 2
      * Entire scrum team gathers to present their task level estimates for
      all stories researched. Doing it in this two-day, two-step way means
      the developers do not come in cold to estimate low-level tasks that
      directly affect what they commit to provide at the end of the sprint.
      At the end of this meeting, the team agrees on a backlog for the sprint.

      The questions we have are: Does this make sense? Is it inefficient?
      Do you have any experiences to share?

      Thanks in advance.
      mike y

      Nicholas Cancelliere, Austin TX
      "The wide world is all about you: you can fence yourselves in, but you cannot for ever fence it out." -Gildor, Fellowship of the Ring (Lord of the Rings)
    • Show all 28 messages in this topic