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

Re: [scrumdevelopment] what benefits can sub tasking bring to developers?

Expand Messages
  • Ron Jeffries
    ... Pair programming? Ron Jeffries www.XProgramming.com I could be wrong. I frequently am.
    Message 1 of 12 , Mar 1, 2006
    • 0 Attachment
      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?

      Ron Jeffries
      www.XProgramming.com
      I could be wrong. I frequently am.
    • Thierry Thelliez
      Here is what we usually do: 1- Sprint Review with everybody around the table (dev team, support, marketing,...) 1a- 5 minutes overview of the Sprint. A copy of
      Message 2 of 12 , Mar 2, 2006
      • 0 Attachment
        Here is what we usually do:

        1- Sprint Review with everybody around the table (dev team, support,
        marketing,...)
        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.



        Thierry Thelliez


        ________________________________________
        From: scrumdevelopment@yahoogroups.com
        [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Alex Pukinskis
        Sent: Tuesday, February 28, 2006 9:38 PM
        To: scrumdevelopment@yahoogroups.com
        Subject: Re: [scrumdevelopment] Sprint Review vs Serial Report

        Are you doing demos of working software in your Review?  Don’t 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?

        -Alex
        ________________________________________
      Your message has been successfully submitted and would be delivered to recipients shortly.