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

Re: what benefits can sub tasking bring to developers?

Expand Messages
  • Deb
    Yes, ideally the tasks could be noted on the story card, at the beginning when they are learning their environment etc. and you could estimate at story level.
    Message 1 of 12 , Mar 1, 2006
    • 0 Attachment
      Yes, ideally the tasks could be noted on the story card, at the
      beginning when they are learning their environment etc. and you could
      estimate at story level.

      But in teams with (gasp!) specialization, units smaller than stories
      may be needed. When 'experts' show up in this way in the process, use
      it as a chance to cross train! Then you won't need a separate task in
      future.

      deb

      --- In scrumdevelopment@yahoogroups.com, Ron Jeffries
      <ronjeffries@...> wrote:
      >
      > 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
      > www.XProgramming.com
      > It is a bad plan that admits of no modifications. -- Publius Syrus
      (ca. 42 BCE)
      >
    • Jeff Heinen
      What if a story requires effort from more than just one person?
      Message 2 of 12 , Mar 1, 2006
      • 0 Attachment
        What if a story requires effort from more than just one person?

        > -----Original Message-----
        > From: scrumdevelopment@yahoogroups.com
        > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Ron Jeffries
        > Sent: Wednesday, March 01, 2006 1:44 AM
        > To: scrumdevelopment@yahoogroups.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
        > www.XProgramming.com
        > 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:
        > scrumdevelopment-unsubscribe@...
        > Yahoo! Groups Links
        >
        >
        >
        >
        >
        >
        >
        >
      • Ron Jeffries
        ... Pair programming? Ron Jeffries www.XProgramming.com I could be wrong. I frequently am.
        Message 3 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 4 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.