21323Re: [scrumdevelopment] Sprint Review and Planning Process
- May 2, 20074 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.
NicholasOn 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
* PO and research manager combine their separate lists into one
Day One - Review
* Scrum team holds sprint review, gets feedback from PO, researchers,
* 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.
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)
- << Previous post in topic Next post in topic >>