Re: [scrumdevelopment] what benefits can sub tasking bring to developers?
- On Wednesday, March 1, 2006, at 9:56:43 AM, Jeff Heinen wrote:
> What if a story requires effort from more than just one person?Pair programming?
I could be wrong. I frequently am.
- Here is what we usually do:
1- Sprint Review with everybody around the table (dev team, support,
1a- 5 minutes overview of the Sprint. A copy of the burndown chart
is used to show the main events of the Sprint. Picks due to bug, support,
sick leave,... The high level obstacles are discussed.
1b- About 1hour: demos. This part is driven by a simple digital
picture of a white board we have in our 'team room' during the Sprint. We go
through everything we can demo. This is where we have some 'serial-report'
type of attitude. For the items we cannot demo we also briefly discuss what
happened (obstacles, issues,...).
1c- About 5 to 30 minutes: We discuss what should be on the next
Sprint. In general the top of the product backlog has already been well
discussed in another forum. We usually have some last minute support request
that we negotiate against the other backlog items.
2- Sprint Retrospective and Planning: (dev team)
2a- Introspection for 5 minutes: What can we do different? We have 2
week Sprints and I rarely get any inputs here... (I will use some of the
ideas I have seen in this thread to improve here).
2b- Planning for about 30 minutes: From Sprint Review Inputs we
update our Team white board. Because we have different skills and expertise,
we always have the same people signing for the same task types. The UI will
be done by the UI developer... This is probably where having heterogeneous
team members is not helping people seeing outside their tasks.
[mailto:email@example.com] On Behalf Of Alex Pukinskis
Sent: Tuesday, February 28, 2006 9:38 PM
Subject: Re: [scrumdevelopment] Sprint Review vs Serial Report
Are you doing demos of working software in your Review? Dont UI and
backend people have to come together to make these demos actually work?
I frequently see teams spending 30 minutes to 1 hour on Sprint demos, 5 to
20 minutes on Sprint Review (usually the ScrumMaster just listing stats
work done vs. committed, defects, test coverage, build success, etc) and 30
minutes to 4 hours on the retrospective. Is your meeting wildly different
than these ranges? Which part of the meeting are you struggling with?