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

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

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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.