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

Estimating and Summing Sprint backlog items

Expand Messages
  • Chuck B
    I have to correct myself in a recent thread. In that thread(see below for thread context), I said: I recommend estimating Sprint tasks in ideal hours
    Message 1 of 11 , Apr 24, 2011
    • 0 Attachment
      I have to correct myself in a recent thread.

      In that thread(see below for thread context), I said:
      <snip>
      I recommend estimating Sprint tasks in ideal hours for the following reasons:
      • ...
      • because it's a rule in the Scrum Guide...
      </snip>

      Well, it appears that in the Feb 2010 version of the Scrum Guide, this rule was changed.

      From the May 2009 Scrum Guide:
      "...As tasks are worked on or completed, the hours of estimated remaining work for each task is updated..."

      From the Feb 2010 Scrum Guide:
      "...As tasks are worked on or completed, the estimated remaining work for each task is updated..."

      Another quote from the most recent Scrum Guide
      "[The Sprint Backlog Burndown is created by]...summing the [Sprint]backlog estimates every day of the Sprint.")

      Be careful on the question I'm about to ask.  Note the specific wording and bolded text.  I'm not speaking of estimating product backlog items... I'm speaking of estimating sprint backlog items, sometimes called sprint "tasks".

      Does anyone know of a credible/vetted/proven/good strategy, other than hours, for being able to *estimate sprint backlog items * and *sum remaining sprint backlog estimates* every day?
       
      -------
      Charles Bradley, CSM, PSM I
      Experienced Scrum Coach
      My blog: http://scrumcrazy.wordpress.com/



      From: Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...>
      To: scrumdevelopment@yahoogroups.com
      Sent: Fri, April 1, 2011 9:44:08 AM
      Subject: Re: [scrumdevelopment] Poll: Hours or Story Points?

      > 1. How do you generate your sprint burndown charts? Considering hours or
      > story points?

      I just count the ideal hours of tasks that are not in the "done" column on the Scrum Board.  

      > 2. Why?

      I recommend estimating Sprint tasks in ideal hours for the following reasons:
      • because I believe that to be the most accurate and transparent method of Scrum tasking (~5-6 ideal hours per day of Scrum tasks).
      • because it's a rule in the Scrum Guide.
      • because it's easier for humans to inspect and adapt their task estimating if it's in hours.  So, eventually, the ideal hours converge towards the real/actual hours if the team continues to improve that skill.
      • because most humans are experienced in estimating in hours prior to beginning Scrum.
      • because it's easier to compare ideal hours remaining in the sprint to ideal hours of capacity left in the sprint.
      While the other methods mentioned so far are good, I do not believe that they are the best, because each lacks some amount of transparency.  Not a lot lacking, just some small amount.  OTOH, there is slightly more overhead in counting ideal task hours vs. counting stories or tasks.  Instead of it taking 5 seconds (counting stories) or 20 seconds (counting tasks), it takes approximately 60-90 seconds to count ideal task hours.  (Obviously, I think the extra minute a day is well worth the accuracy and transparency that that particular method provides).

      -------
      Charles Bradley, CSM, PSM I
      Experienced Scrum Coach
      My blog: http://scrumcrazy.wordpress.com/

       

    • Alan Dayley
      I have seen estimation of remaining work for tasks: - in hours, as in hours as defined by a clock - in ideal hours - in task points, which this particular
      Message 2 of 11 , Apr 25, 2011
      • 0 Attachment
        I have seen estimation of remaining work for tasks:
        - in hours, as in hours as defined by a clock
        - in ideal hours
        - in "task points," which this particular team defined as different than "story points"
        - null, as in they did not estimate tasks at all but burned down Sprint Backlog stories as they completed.

        I have seen these all work, to some degree.  And seen some of them fail, in that the teams failed to deliver in a sprint and these estimate methods were in use as part of the failure.  There is not a "one and only way" to do task estimates and burndown/burnup tracking.  For any given team, in any given organization, at any given time, any one method could be helpful or could be an impediment.

        What is the purpose of your question?

        Alan

        On Sun, Apr 24, 2011 at 5:53 PM, Chuck B <chuck-lists2@...> wrote:
         

        I have to correct myself in a recent thread.

        In that thread(see below for thread context), I said:
        <snip>
        I recommend estimating Sprint tasks in ideal hours for the following reasons:
        • ...
        • because it's a rule in the Scrum Guide...
        </snip>

        Well, it appears that in the Feb 2010 version of the Scrum Guide, this rule was changed.

        From the May 2009 Scrum Guide:
        "...As tasks are worked on or completed, the hours of estimated remaining work for each task is updated..."

        From the Feb 2010 Scrum Guide:
        "...As tasks are worked on or completed, the estimated remaining work for each task is updated..."

        Another quote from the most recent Scrum Guide
        "[The Sprint Backlog Burndown is created by]...summing the [Sprint]backlog estimates every day of the Sprint.")

        Be careful on the question I'm about to ask.  Note the specific wording and bolded text.  I'm not speaking of estimating product backlog items... I'm speaking of estimating sprint backlog items, sometimes called sprint "tasks".

        Does anyone know of a credible/vetted/proven/good strategy, other than hours, for being able to *estimate sprint backlog items * and *sum remaining sprint backlog estimates* every day?
         
        -------
        Charles Bradley, CSM, PSM I
        Experienced Scrum Coach
        My blog: http://scrumcrazy.wordpress.com/



        From: Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...>
        To: scrumdevelopment@yahoogroups.com
        Sent: Fri, April 1, 2011 9:44:08 AM
        Subject: Re: [scrumdevelopment] Poll: Hours or Story Points?

        > 1. How do you generate your sprint burndown charts? Considering hours or
        > story points?

        I just count the ideal hours of tasks that are not in the "done" column on the Scrum Board.  

        > 2. Why?

        I recommend estimating Sprint tasks in ideal hours for the following reasons:
        • because I believe that to be the most accurate and transparent method of Scrum tasking (~5-6 ideal hours per day of Scrum tasks).
        • because it's a rule in the Scrum Guide.
        • because it's easier for humans to inspect and adapt their task estimating if it's in hours.  So, eventually, the ideal hours converge towards the real/actual hours if the team continues to improve that skill.
        • because most humans are experienced in estimating in hours prior to beginning Scrum.
        • because it's easier to compare ideal hours remaining in the sprint to ideal hours of capacity left in the sprint.
        While the other methods mentioned so far are good, I do not believe that they are the best, because each lacks some amount of transparency.  Not a lot lacking, just some small amount.  OTOH, there is slightly more overhead in counting ideal task hours vs. counting stories or tasks.  Instead of it taking 5 seconds (counting stories) or 20 seconds (counting tasks), it takes approximately 60-90 seconds to count ideal task hours.  (Obviously, I think the extra minute a day is well worth the accuracy and transparency that that particular method provides).

        -------
        Charles Bradley, CSM, PSM I
        Experienced Scrum Coach
        My blog: http://scrumcrazy.wordpress.com/

         


      • Charles Bradley - Scrum Coach CSM PSM I
        Alan, Purposes of my question: * Primarily, to survey other Scrum mature people like yourself as to other techniques that exist, as well as the effectiveness
        Message 3 of 11 , Apr 25, 2011
        • 0 Attachment
          Alan,

          Purposes of my question:
          • Primarily, to survey other "Scrum mature" people like yourself as to other techniques that exist, as well as the effectiveness of those techniques. 
          • Secondarily, to gather information for an article I'm writing entitled "Sprint Tasking Tips"
          • Thirdly, to maybe discuss some of the techniques with those on this discussion list.
           
          -------
          Charles Bradley, CSM, PSM I
          Experienced Scrum Coach
          My blog: http://scrumcrazy.wordpress.com/



          From: Alan Dayley <alandd@...>
          To: scrumdevelopment@yahoogroups.com
          Sent: Mon, April 25, 2011 9:38:20 AM
          Subject: Re: [scrumdevelopment] Estimating and Summing Sprint backlog items



          I have seen estimation of remaining work for tasks:
          - in hours, as in hours as defined by a clock
          - in ideal hours
          - in "task points," which this particular team defined as different than "story points"
          - null, as in they did not estimate tasks at all but burned down Sprint Backlog stories as they completed.

          I have seen these all work, to some degree.  And seen some of them fail, in that the teams failed to deliver in a sprint and these estimate methods were in use as part of the failure.  There is not a "one and only way" to do task estimates and burndown/burnup tracking.  For any given team, in any given organization, at any given time, any one method could be helpful or could be an impediment.

          What is the purpose of your question?

          Alan

          On Sun, Apr 24, 2011 at 5:53 PM, Chuck B <chuck-lists2@...> wrote:
           

          I have to correct myself in a recent thread.

          In that thread(see below for thread context), I said:
          <snip>
          I recommend estimating Sprint tasks in ideal hours for the following reasons:
          • ...
          • because it's a rule in the Scrum Guide...
          </snip>

          Well, it appears that in the Feb 2010 version of the Scrum Guide, this rule was changed.

          From the May 2009 Scrum Guide:
          "...As tasks are worked on or completed, the hours of estimated remaining work for each task is updated..."

          From the Feb 2010 Scrum Guide:
          "...As tasks are worked on or completed, the estimated remaining work for each task is updated..."

          Another quote from the most recent Scrum Guide
          "[The Sprint Backlog Burndown is created by]...summing the [Sprint]backlog estimates every day of the Sprint.")

          Be careful on the question I'm about to ask.  Note the specific wording and bolded text.  I'm not speaking of estimating product backlog items... I'm speaking of estimating sprint backlog items, sometimes called sprint "tasks".

          Does anyone know of a credible/vetted/proven/good strategy, other than hours, for being able to *estimate sprint backlog items * and *sum remaining sprint backlog estimates* every day?
           
          -------
          Charles Bradley, CSM, PSM I
          Experienced Scrum Coach
          My blog: http://scrumcrazy.wordpress.com/



          From: Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...>
          To: scrumdevelopment@yahoogroups.com
          Sent: Fri, April 1, 2011 9:44:08 AM
          Subject: Re: [scrumdevelopment] Poll: Hours or Story Points?

          > 1. How do you generate your sprint burndown charts? Considering hours or
          > story points?

          I just count the ideal hours of tasks that are not in the "done" column on the Scrum Board.  

          > 2. Why?

          I recommend estimating Sprint tasks in ideal hours for the following reasons:
          • because I believe that to be the most accurate and transparent method of Scrum tasking (~5-6 ideal hours per day of Scrum tasks).
          • because it's a rule in the Scrum Guide.
          • because it's easier for humans to inspect and adapt their task estimating if it's in hours.  So, eventually, the ideal hours converge towards the real/actual hours if the team continues to improve that skill.
          • because most humans are experienced in estimating in hours prior to beginning Scrum.
          • because it's easier to compare ideal hours remaining in the sprint to ideal hours of capacity left in the sprint.
          While the other methods mentioned so far are good, I do not believe that they are the best, because each lacks some amount of transparency.  Not a lot lacking, just some small amount.  OTOH, there is slightly more overhead in counting ideal task hours vs. counting stories or tasks.  Instead of it taking 5 seconds (counting stories) or 20 seconds (counting tasks), it takes approximately 60-90 seconds to count ideal task hours.  (Obviously, I think the extra minute a day is well worth the accuracy and transparency that that particular method provides).

          -------
          Charles Bradley, CSM, PSM I
          Experienced Scrum Coach
          My blog: http://scrumcrazy.wordpress.com/

           




        • Charles Bradley - Scrum Coach CSM PSM I
          Alan, I too have personally seen all of the methods you describe. (And interestingly, I have seen no other methods, unless you count the null method without
          Message 4 of 11 , Apr 25, 2011
          • 0 Attachment
            Alan,

            I too have personally seen all of the methods you describe.  (And interestingly, I have seen no other methods, unless you count the null method without burning anything down at all as separate method.)

            The one I really didn't like of those 4 was "task points. "  I think that's generally a ludicrous approach.  I'd love to hear a team's context as to why that approach worked well for the team.  I probably wouldn't believe it, but I'd love to hear them try.  :-)

            I could see an advanced team succeeding with the "null" approach if the team is advanced, and *if* their PBI's are all pretty small.  Otherwise, I think the null method is very risky for teams just starting out with Scrum.
             
            -------
            Charles Bradley, CSM, PSM I
            Experienced Scrum Coach
            My blog: http://scrumcrazy.wordpress.com/



            From: Alan Dayley <alandd@...>
            To: scrumdevelopment@yahoogroups.com
            Sent: Mon, April 25, 2011 9:38:20 AM
            Subject: Re: [scrumdevelopment] Estimating and Summing Sprint backlog items



            I have seen estimation of remaining work for tasks:
            - in hours, as in hours as defined by a clock
            - in ideal hours
            - in "task points," which this particular team defined as different than "story points"
            - null, as in they did not estimate tasks at all but burned down Sprint Backlog stories as they completed.

            I have seen these all work, to some degree.  And seen some of them fail, in that the teams failed to deliver in a sprint and these estimate methods were in use as part of the failure.  There is not a "one and only way" to do task estimates and burndown/burnup tracking.  For any given team, in any given organization, at any given time, any one method could be helpful or could be an impediment.

            What is the purpose of your question?

            Alan

            On Sun, Apr 24, 2011 at 5:53 PM, Chuck B <chuck-lists2@...> wrote:
             

            I have to correct myself in a recent thread.

            In that thread(see below for thread context), I said:
            <snip>
            I recommend estimating Sprint tasks in ideal hours for the following reasons:
            • ...
            • because it's a rule in the Scrum Guide...
            </snip>

            Well, it appears that in the Feb 2010 version of the Scrum Guide, this rule was changed.

            From the May 2009 Scrum Guide:
            "...As tasks are worked on or completed, the hours of estimated remaining work for each task is updated..."

            From the Feb 2010 Scrum Guide:
            "...As tasks are worked on or completed, the estimated remaining work for each task is updated..."

            Another quote from the most recent Scrum Guide
            "[The Sprint Backlog Burndown is created by]...summing the [Sprint]backlog estimates every day of the Sprint.")

            Be careful on the question I'm about to ask.  Note the specific wording and bolded text.  I'm not speaking of estimating product backlog items... I'm speaking of estimating sprint backlog items, sometimes called sprint "tasks".

            Does anyone know of a credible/vetted/proven/good strategy, other than hours, for being able to *estimate sprint backlog items * and *sum remaining sprint backlog estimates* every day?
             
            -------
            Charles Bradley, CSM, PSM I
            Experienced Scrum Coach
            My blog: http://scrumcrazy.wordpress.com/



            From: Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...>
            To: scrumdevelopment@yahoogroups.com
            Sent: Fri, April 1, 2011 9:44:08 AM
            Subject: Re: [scrumdevelopment] Poll: Hours or Story Points?

            > 1. How do you generate your sprint burndown charts? Considering hours or
            > story points?

            I just count the ideal hours of tasks that are not in the "done" column on the Scrum Board.  

            > 2. Why?

            I recommend estimating Sprint tasks in ideal hours for the following reasons:
            • because I believe that to be the most accurate and transparent method of Scrum tasking (~5-6 ideal hours per day of Scrum tasks).
            • because it's a rule in the Scrum Guide.
            • because it's easier for humans to inspect and adapt their task estimating if it's in hours.  So, eventually, the ideal hours converge towards the real/actual hours if the team continues to improve that skill.
            • because most humans are experienced in estimating in hours prior to beginning Scrum.
            • because it's easier to compare ideal hours remaining in the sprint to ideal hours of capacity left in the sprint.
            While the other methods mentioned so far are good, I do not believe that they are the best, because each lacks some amount of transparency.  Not a lot lacking, just some small amount.  OTOH, there is slightly more overhead in counting ideal task hours vs. counting stories or tasks.  Instead of it taking 5 seconds (counting stories) or 20 seconds (counting tasks), it takes approximately 60-90 seconds to count ideal task hours.  (Obviously, I think the extra minute a day is well worth the accuracy and transparency that that particular method provides).

            -------
            Charles Bradley, CSM, PSM I
            Experienced Scrum Coach
            My blog: http://scrumcrazy.wordpress.com/

             




          • Charles Bradley - Scrum Coach CSM PSM I
            ... I ve completed the article. Feedback welcome. http://www.scrumcrazy.com/Sprint+Tasking+Tips ... Charles Bradley, CSM, PSM I Experienced Scrum Coach My
            Message 5 of 11 , Apr 26, 2011
            • 0 Attachment
              > Secondarily, to gather information for an article I'm writing entitled "Sprint Tasking Tips"

              I've completed the article.  Feedback welcome.
              http://www.scrumcrazy.com/Sprint+Tasking+Tips

               
              -------
              Charles Bradley, CSM, PSM I
              Experienced Scrum Coach
              My blog: http://scrumcrazy.wordpress.com/



              From: Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...>
              To: scrumdevelopment@yahoogroups.com
              Sent: Mon, April 25, 2011 10:50:27 AM
              Subject: Re: [scrumdevelopment] Estimating and Summing Sprint backlog items



              Alan,

              Purposes of my question:
              • Primarily, to survey other "Scrum mature" people like yourself as to other techniques that exist, as well as the effectiveness of those techniques. 
              • Secondarily, to gather information for an article I'm writing entitled "Sprint Tasking Tips"
              • Thirdly, to maybe discuss some of the techniques with those on this discussion list.
               
              -------
              Charles Bradley, CSM, PSM I
              Experienced Scrum Coach
              My blog: http://scrumcrazy.wordpress.com/

            • Andrew Pham
              ... Hi Chuck, I don t know if I had completely understood your question but if I have, I always end up recommending to Agile teams to estimate their user
              Message 6 of 11 , Apr 28, 2011
              • 0 Attachment
                On Sun, Apr 24, 2011 at 7:53 PM, Chuck B <chuck-lists2@...> wrote:
                 

                I have to correct myself in a recent thread.

                In that thread(see below for thread context), I said:
                <snip>
                I recommend estimating Sprint tasks in ideal hours for the following reasons:
                • ...
                • because it's a rule in the Scrum Guide...
                </snip>

                Well, it appears that in the Feb 2010 version of the Scrum Guide, this rule was changed.

                From the May 2009 Scrum Guide:
                "...As tasks are worked on or completed, the hours of estimated remaining work for each task is updated..."

                From the Feb 2010 Scrum Guide:
                "...As tasks are worked on or completed, the estimated remaining work for each task is updated..."

                Another quote from the most recent Scrum Guide
                "[The Sprint Backlog Burndown is created by]...summing the [Sprint]backlog estimates every day of the Sprint.")

                Be careful on the question I'm about to ask.  Note the specific wording and bolded text.  I'm not speaking of estimating product backlog items... I'm speaking of estimating sprint backlog items, sometimes called sprint "tasks".

                Does anyone know of a credible/vetted/proven/good strategy, other than hours, for being able to *estimate sprint backlog items * and *sum remaining sprint backlog estimates* every day?

                Hi Chuck,

                I don't know if I had completely understood your question but if I have, I always end up recommending to Agile teams to estimate their user stories in story points and then decompose the user stories into tasks which are to be estimated in hours. We then sum them up and use these (hours) to calculate the remaining work (in hours) in updating the daily burndown chart...

                Regards,

                Andrew Pham
                Author of Scrum in Action
                http://www.amazon.com/Scrum-Action-Andrew-Pham/dp/143545913X/ref=ntt_at_ep_dpi_1-1
                 
                -------
                Charles Bradley, CSM, PSM I
                Experienced Scrum Coach
                My blog: http://scrumcrazy.wordpress.com/



                From: Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...>
                To: scrumdevelopment@yahoogroups.com
                Sent: Fri, April 1, 2011 9:44:08 AM
                Subject: Re: [scrumdevelopment] Poll: Hours or Story Points?

                > 1. How do you generate your sprint burndown charts? Considering hours or
                > story points?

                I just count the ideal hours of tasks that are not in the "done" column on the Scrum Board.  

                > 2. Why?

                I recommend estimating Sprint tasks in ideal hours for the following reasons:
                • because I believe that to be the most accurate and transparent method of Scrum tasking (~5-6 ideal hours per day of Scrum tasks).
                • because it's a rule in the Scrum Guide.
                • because it's easier for humans to inspect and adapt their task estimating if it's in hours.  So, eventually, the ideal hours converge towards the real/actual hours if the team continues to improve that skill.
                • because most humans are experienced in estimating in hours prior to beginning Scrum.
                • because it's easier to compare ideal hours remaining in the sprint to ideal hours of capacity left in the sprint.
                While the other methods mentioned so far are good, I do not believe that they are the best, because each lacks some amount of transparency.  Not a lot lacking, just some small amount.  OTOH, there is slightly more overhead in counting ideal task hours vs. counting stories or tasks.  Instead of it taking 5 seconds (counting stories) or 20 seconds (counting tasks), it takes approximately 60-90 seconds to count ideal task hours.  (Obviously, I think the extra minute a day is well worth the accuracy and transparency that that particular method provides).

                -------
                Charles Bradley, CSM, PSM I
                Experienced Scrum Coach
                My blog: http://scrumcrazy.wordpress.com/

                 


              • Charles Bradley - Scrum Coach CSM PSM I
                Andrew, ... chart... I do too, though I generally recommend ideal hours. I had one client who was a consulting firm and it made things much easier for their
                Message 7 of 11 , Apr 29, 2011
                • 0 Attachment
                  Andrew,

                  > I
                  don't know if I had completely understood your question but if I have,
                  > I always end up recommending to Agile teams to estimate their user
                  stories
                  > in story points and then decompose the user stories into tasks
                  which are
                  > to be estimated in hours. We then sum them up and use these
                  (hours) to
                  > calculate the remaining work (in hours) in updating the
                  daily burndown chart...

                  I do too, though I generally recommend ideal hours.  I had one client who was a consulting firm and it made things much easier for their billing purposes to use "real hours" (~8/day).
                  More on that subject here: 

                  Sprint Tasking Tips
                  http://www.scrumcrazy.com/Sprint+Tasking+Tips

                  What I was asking is if anyone uses some credible method other than hours for Sprint Backlog Item(aka task) estimates.  So far I think only Alan had some other methods.

                   -------
                  Charles Bradley, CSM, PSM I
                  Experienced Scrum Coach
                  My blog: http://scrumcrazy.wordpress.com/
                • George Dinwiddie
                  Charles, ... Perhaps others, like me, didn t realize that was your question. I don t recommend estimating tasks. I don t recommend creating the Sprint Backlog
                  Message 8 of 11 , Apr 29, 2011
                  • 0 Attachment
                    Charles,

                    On 4/29/11 11:55 AM, Charles Bradley - Scrum Coach CSM PSM I wrote:
                    > What I was asking is if anyone uses some credible method other than
                    > hours for Sprint Backlog Item(aka task) estimates. So far I think only
                    > Alan had some other methods.

                    Perhaps others, like me, didn't realize that was your question.

                    I don't recommend estimating tasks. I don't recommend creating the
                    Sprint Backlog from task decomposition of the User Stories.

                    Instead, I've found it better to put thinly sliced stories on the Sprint
                    Backlog and track those. Stories have an advantage over tasks in that
                    they have demonstrable functionality, expressed as tests. With stories
                    there's no little piece left out of the estimation but necessary for
                    accomplishing the functionality (the old 10% of the job that takes 90%
                    of the time). With stories, there's no focus on "I've done my task" by
                    specialists because the item isn't done until it's functional.

                    I don't recommend estimating the thinly sliced stories, either.
                    Alternatively, I recommend estimating them all as 1 point. If there are
                    a lot of examples needed to distill the essence of the story, then I
                    recommend clumping those examples in small groups and calling each a
                    story slice of 1 point. This is a good technique for making story
                    counting work as well, or better, than story estimation.

                    I recommend these things because I find they work more reliably with
                    less wasted effort. They're not the only way to work, of course, and if
                    a team is delivering well using the daily re-estimation of tasks as
                    described in the Scrum Guide, then I wouldn't worry too much about it.
                    If they're running into difficulties, then I'd recommend modifying the
                    practices that are enabling their difficulties. If they were just
                    starting out, I'd suggest they start with thinly sliced stories
                    illustrated by examples.

                    - George

                    --
                    ----------------------------------------------------------------------
                    * George Dinwiddie * http://blog.gdinwiddie.com
                    Software Development http://www.idiacomputing.com
                    Consultant and Coach http://www.agilemaryland.org
                    ----------------------------------------------------------------------
                  • Charles Bradley - Scrum Coach CSM PSM I
                    George, Good post. ... My question presumed that you estimate tasks much like what they describe in the Scrum Guide. (updating of task estimates is a whole
                    Message 9 of 11 , Apr 29, 2011
                    • 0 Attachment
                      George,

                      Good post. 

                      > I don't recommend estimating tasks.  I don't recommend creating the
                      > Sprint Backlog from task decomposition of the User Stories.
                      My question presumed that you estimate tasks much like what they describe in the Scrum Guide.

                       (updating of task estimates is a whole different issue, I won't open the can of worms on that)


                      -------
                      Charles Bradley, CSM, PSM I
                      Experienced Scrum Coach
                      My blog: http://scrumcrazy.wordpress.com/



                      From: George Dinwiddie <lists@...>
                      To: scrumdevelopment@yahoogroups.com
                      Sent: Fri, April 29, 2011 1:36:55 PM
                      Subject: Re: [scrumdevelopment] Estimating and Summing Sprint backlog items

                      Charles,

                      On 4/29/11 11:55 AM, Charles Bradley - Scrum Coach CSM PSM I wrote:
                      > What I was asking is if anyone uses some credible method other than
                      > hours for Sprint Backlog Item(aka task) estimates. So far I think only
                      > Alan had some other methods.

                      Perhaps others, like me, didn't realize that was your question.

                      I don't recommend estimating tasks.  I don't recommend creating the
                      Sprint Backlog from task decomposition of the User Stories.

                      Instead, I've found it better to put thinly sliced stories on the Sprint
                      Backlog and track those.  Stories have an advantage over tasks in that
                      they have demonstrable functionality, expressed as tests.  With stories
                      there's no little piece left out of the estimation but necessary for
                      accomplishing the functionality (the old 10% of the job that takes 90%
                      of the time).  With stories, there's no focus on "I've done my task" by
                      specialists because the item isn't done until it's functional.

                      I don't recommend estimating the thinly sliced stories, either.
                      Alternatively, I recommend estimating them all as 1 point.  If there are
                      a lot of examples needed to distill the essence of the story, then I
                      recommend clumping those examples in small groups and calling each a
                      story slice of 1 point.  This is a good technique for making story
                      counting work as well, or better, than story estimation.

                      I recommend these things because I find they work more reliably with
                      less wasted effort.  They're not the only way to work, of course, and if
                      a team is delivering well using the daily re-estimation of tasks as
                      described in the Scrum Guide, then I wouldn't worry too much about it.
                      If they're running into difficulties, then I'd recommend modifying the
                      practices that are enabling their difficulties.  If they were just
                      starting out, I'd suggest they start with thinly sliced stories
                      illustrated by examples.

                        - George

                      --
                        ----------------------------------------------------------------------
                        * George Dinwiddie *                      http://blog.gdinwiddie.com
                        Software Development                    http://www.idiacomputing.com
                        Consultant and Coach                    http://www.agilemaryland.org
                        ----------------------------------------------------------------------



                      ------------------------------------

                      To Post a message, send it to:  scrumdevelopment@...
                      To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

                      <*> To visit your group on the web, go to:
                          http://groups.yahoo.com/group/scrumdevelopment/

                      <*> Your email settings:
                          Individual Email | Traditional

                      <*> To change settings online go to:
                          http://groups.yahoo.com/group/scrumdevelopment/join
                          (Yahoo! ID required)

                      <*> To change settings via email:
                          scrumdevelopment-digest@yahoogroups.com
                          scrumdevelopment-fullfeatured@yahoogroups.com

                      <*> To unsubscribe from this group, send an email to:
                          scrumdevelopment-unsubscribe@yahoogroups.com

                      <*> Your use of Yahoo! Groups is subject to:
                          http://docs.yahoo.com/info/terms/

                    • avi_a@mapa.co.il
                      Charles - Excellent article! The What scrum guide says part gives a good starting, and the goals of the tips gives an excellent focus on the if and why
                      Message 10 of 11 , Apr 30, 2011
                      • 0 Attachment
                        Charles - Excellent article!

                        The "What scrum guide says" part gives a good starting, and the "goals of the tips" gives an excellent focus on the "if and why should we be reading this". The tips themselves are very concise and practical.

                        I went through it the other day and passed it on to my team as well.
                        We've been experiencing some tasking trouble and the article came just in the right time for us..

                        In fact we conducted an entire retrospect around it - going through the tips, examining which of them we were already using, which might be worth adopting and decided on some tips that we would use during the upcoming sprint to try and remedy the situation.

                        I must say that tip #15 got us especially intrigued - we found we were having tiny tasks, many of them quarter-hour or half hour tasks, and some "5 minute" tasks (like "run the automated tests to make sure we haven't broken anything").
                        Retrospecting we found that we did in fact have atomic tasks taking us half an hour so we decided to adopt the tip with rounding and batching tasks to be no less than 0.5 hour instead of 1 hour. (We're using pomodoro technique for time management so it makes sense that work will tend to fill half-hour chunks).
                        During the tasking session afterwards we definitely saw the benefits of this - we ended up with less micro-tasks and an overall shorter list of tasks, making better transparency and hopefully better efficiency in the end of the sprint (of course we've yet to see about it in the end).

                        Some other tips I might suggest:
                        1. Regarding work required by external people (a-la a this seperate thread :
                        http://groups.yahoo.com/group/scrumdevelopment/message/50915)
                        If we identify work required by external people we estimate only the effort required by our team (like pairing with the external people) bu we add a separate "outsourcing list" of things required from external parties, estimating in it how much of //their// time is required and when it is needed and possible to get. This helps our team's work and reduce bottlenecks and critical-path risk due to the external parties availability. If necessary, we would also add a task to the sprint backlog saying "coordinate external work".

                        2. Add a "total work" line in the burndown chart:
                        Sum the total effort each day and plot a line in the burndown for it.
                        If the entire sprint work doesn't change throughout the sprint this line will remain straight, although more likely there will be added and removed tasks during the sprint or reestimating of remaining effort, causing the line to go up or down.
                        This line can be useful during retrospecting - if we see the line went up a lot during the sprint it means we probably didn't think through all the tasks in the beginning.
                        Although this is normal and understandable (after all, you can't predict everything), if the team runs into recurring situations where they don't complete their committed work we might find the line was going up too much, hinting that under-tasking might cause the team to over-commit.


                        We havn't had a chance to inspect all the tips yet, and the link to the "Bad smells of the sprint backlog" article also caught my eye, hopefully we will make use of it as well.

                        Thanks again,
                        -Avi


                        --- In scrumdevelopment@yahoogroups.com, Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...> wrote:
                        >
                        > > Secondarily, to gather information for an article I'm writing entitled "Sprint
                        > >Tasking Tips"
                        >
                        > I've completed the article. Feedback welcome.
                        > http://www.scrumcrazy.com/Sprint+Tasking+Tips
                        >
                        >
                        > -------
                        > Charles Bradley, CSM, PSM I
                        > Experienced Scrum Coach
                        > My blog: http://scrumcrazy.wordpress.com/
                        >
                        >
                        >
                        >
                        > ________________________________
                        > From: Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...>
                        > To: scrumdevelopment@yahoogroups.com
                        > Sent: Mon, April 25, 2011 10:50:27 AM
                        > Subject: Re: [scrumdevelopment] Estimating and Summing Sprint backlog items
                        >
                        >
                        >
                        >
                        > Alan,
                        >
                        > Purposes of my question:
                        >
                        > * Primarily, to survey other "Scrum mature" people like yourself as to other
                        > techniques that exist, as well as the effectiveness of those techniques.
                        >
                        > * Secondarily, to gather information for an article I'm writing entitled
                        > "Sprint Tasking Tips"
                        > * Thirdly, to maybe discuss some of the techniques with those on this
                        > discussion list.
                        > -------
                        > Charles Bradley, CSM, PSM I
                        > Experienced Scrum Coach
                        > My blog: http://scrumcrazy.wordpress.com/
                        >
                      • Wouter Lagerweij
                        Hi Alan, One option I don‘t see mentioned (whch happens t be one I default to) is not estimating tasks explicitly, but do burning them up in a sprint
                        Message 11 of 11 , May 8 5:39 AM
                        • 0 Attachment

                          Hi Alan,

                          One option I don‘t see mentioned (whch happens t be one I default to)  is not estimating tasks explicitly, but do burning them up in a sprint burn-up cart simply with the number of tasks done
                          In this case I do have an agreement with the team that tasks shouldn‘t take longer than roughly half a day (only needed for inexperienced teams).
                          The nice thing is that you don‘t waste time eztimatibg lots of small tasks, but you do get a good idea of tasks being added during the sprint.

                          Wouter

                          On 25 Apr 2011 17:38, "Alan Dayley" <alandd@...> wrote:
                        Your message has been successfully submitted and would be delivered to recipients shortly.