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

Re: what benefits can sub tasking bring to developers?

Expand Messages
  • Deb
    Hello Kitty1 (guess you hear that a lot? :-) Your reasons are sensible, and I d add one more: with more granular units of work the burndown can be easier to
    Message 1 of 12 , Mar 1, 2006
    • 0 Attachment
      Hello Kitty1 (guess you hear that a lot? :-)

      Your reasons are sensible, and I'd add one more: with more granular
      units of work the burndown can be easier to update. Sometimes a big
      item with lots of uncertainty burns down like 10-10-7-7-0, you have
      flatlining and sudden drops. Burndown is easier to update and guage,
      in my opinion, when stories or task are <= 10% of sprint length. The
      burndown is very much a developer tool, not just for the SM. The
      developers are on the hook to deliver, not the SM.

      > these two points are more likely for management purpose

      Yes, and amazingly, Agile management can have benefits for developers,
      too! :-D

      > How can we persuade developers to do this?

      I'd say, wait till there is a problem, and if they don't suggest it
      themselves, you might ask them what they think. Best way to get more
      agile, in my book, is to apply the practice "where it hurts". I
      believe that some XP teams do estimate at the story level, and that's
      fine.

      Where might this practice (small estimation units) help? Using the
      burndown but still not making the target may be one. Idle people may
      be another (smaller units can be more easily shared). Bottlenecks
      could be a third. Anyone else have ideas on this?

      I find that more granularity at the beginning can help the team learn
      to estimate, once they have learned this the best granularity is
      whatever works for them. Still, <=10% reduces risk, when unknowns crop
      up, which they will.

      best of luck
      deb


      --- In scrumdevelopment@yahoogroups.com, kittys shu
      <kittyscalgary@...> wrote:
      >
      > My current research is to conduct an empirical study on the effect
      of Scrum.
      >
      > After several months' effort, the PM I work with finally agreed to
      try scrum in his project.
      >
      > Since everything just started, there are some questions and issues
      appearing.
      >
      > One of his questions is why do we do sub tasking, why don't we
      just end with selecting user stories for current iteration? I gave him
      two points as the answer: 1. sub tasking and time estimation force
      developers to think thoroughly what they are going to do with the user
      stories. So, they may find out that some stories that are originally
      thought feasible become not feasible so that they cannot go into the
      current iteration. This is good for iteration planning and results.
      >
      > 2. when we move the tasks to the "completed" list, healthy peer
      pressure can be achieved.
      >
      > However, he thought these two points are more likely for
      management purpose.
      >
      > 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?
      >
      >
      >
      >
      > ---------------------------------
      > Find your next car at Yahoo! Canada Autos
      >
    • 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 2 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 3 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 4 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 5 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.