21347Re: Sprint Review and Planning Process
- May 3, 2007Sprints are four weeks (i.e. one month).
--- In firstname.lastname@example.org, "Michael Vizdos"
> Eeeek... Lots of red flags going off on this for me right now.
> First question:
> How long are your Sprints or Iterations?
> - mike
> On 5/2/07, myoungtai <myoungtai@...> wrote:
> > Scrummers,
> > I am looking for a critique and some ideas regarding the sprint review
> > and planning process.
> > Background:
> > 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.
> > Solution:
> > 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
> > The questions we have are: Does this make sense? Is it inefficient?
> > Do you have any experiences to share?
> > Thanks in advance.
> > mike y
- << Previous post in topic Next post in topic >>