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

what benefits can sub tasking bring to developers?

Expand Messages
  • kittys shu
    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
    Message 1 of 12 , Feb 28, 2006
    • 0 Attachment
      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
    • Ron Jeffries
      ... 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,
      Message 2 of 12 , Mar 1, 2006
      • 0 Attachment
        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)
      • 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 3 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 4 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 5 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 6 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 7 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.