RE: [scrumdevelopment] what benefits can sub tasking bring to developers?
- What if a story requires effort from more than just one person?
> -----Original Message-----
> From: email@example.com
> [mailto:firstname.lastname@example.org] On Behalf Of Ron Jeffries
> Sent: Wednesday, March 01, 2006 1:44 AM
> To: email@example.com
> Subject: Re: [scrumdevelopment] what benefits can sub tasking
> bring to developers?
> On Tuesday, February 28, 2006, at 10:50:24 PM, kittys shu wrote:
> > How can we persuade developers to do this? Or, in other
> words, what
> > are the big and obvious benefits for them to show their
> private working steps?
> I like to see the team brainstorm the technical tasks that
> are to be done, but to see user stories signed up for, not
> tasks. (By the way "user story" is, as far as I know, an XP
> term, not a Scrum term.)
> Brainstorming the technical tasks is an explicit albeit small
> design step and therefore it benefits the team by keeping
> everyone aware of the intended design of each story, and
> allowing everyone to contribute.
> Signing up for stories rather than tasks keeps the team
> focused on story completion, not task completion. Thus, I prefer it.
> Ron Jeffries
> It is a bad plan that admits of no modifications. -- Publius
> Syrus (ca. 42 BCE)
> To Post a message, send it to: scrumdevelopment@...
> To Unsubscribe, send a blank message to:
> Yahoo! Groups Links
- 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:firstname.lastname@example.org] 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?