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

using story points to estimate tasks

Expand Messages
  • Tobias Mayer
    I recently heard that some CSM trainers are recommending that teams use story points to estimate the size of tasks. This baffles me. I think they are called
    Message 1 of 11 , Jan 29, 2008
    • 0 Attachment

      I recently heard that some CSM trainers are recommending that teams use story points to estimate the size of tasks.   This baffles me.  I think they are called story points for a reason: they are used to measure the relative size of stories.

      I don't encourage teams to estimate task size at all except to ensure that a task is small enough to move from "In Progress" to "Done" in a single day, but I understand that some teams successfully use real time (i.e. hours) to estimate task size.   I think it is an unnecessary, perhaps even wasteful practice, but at least it makes sense.

      I can't make sense of the idea of sizing tasks in story points.  Should all the task-story-points add up to the total size of the story?  What if you add a new task later on?   I'd be very interested in hearing how this system works, how it helps.   My instinct is to dismiss it... but I have made that mistake before (!) so now I seek enlightenment.  Anyone?

      Cheers.
      Tobias
      http://agilethinking.net 

    • Rob Park
      Personally, I still don t like the idea of estimating tasks, period. IMO, it s good to discuss tasks to come up with an estimate for a story, but I don t even
      Message 2 of 11 , Jan 29, 2008
      • 0 Attachment
        Personally, I still don't like the idea of estimating tasks, period.

        IMO, it's good to discuss tasks to come up with an estimate for a story, but I don't even want to track tasks done within a story, because to me it's a false estimator towards done.  Done is done when the story is done.

        .rob.

        On Jan 29, 2008 5:44 PM, Tobias Mayer <tobyanon@...> wrote:


        I recently heard that some CSM trainers are recommending that teams use story points to estimate the size of tasks.   This baffles me.  I think they are called story points for a reason: they are used to measure the relative size of stories.

        I don't encourage teams to estimate task size at all except to ensure that a task is small enough to move from "In Progress" to "Done" in a single day, but I understand that some teams successfully use real time (i.e. hours) to estimate task size.   I think it is an unnecessary, perhaps even wasteful practice, but at least it makes sense.

        I can't make sense of the idea of sizing tasks in story points.  Should all the task-story-points add up to the total size of the story?  What if you add a new task later on?   I'd be very interested in hearing how this system works, how it helps.   My instinct is to dismiss it... but I have made that mistake before (!) so now I seek enlightenment.  Anyone?

        Cheers.
        Tobias
        http://agilethinking.net 


      • George Dinwiddie
        ... I agree that estimating tasks is wasteful, but it s helpful for many teams new to Agile and is not their biggest waste. When you really get going, though,
        Message 3 of 11 , Jan 29, 2008
        • 0 Attachment
          Tobias Mayer wrote:
          >
          > I recently heard that some CSM trainers are recommending that teams use
          > story points to estimate the size of tasks. This baffles me. I think
          > they are called story points for a reason: they are used to measure the
          > relative size of stories.
          >
          > I don't encourage teams to estimate task size at all except to ensure
          > that a task is small enough to move from "In Progress" to "Done" in a
          > single day, but I understand that some teams successfully use real time
          > (i.e. hours) to estimate task size. I think it is an unnecessary,
          > perhaps even wasteful practice, but at least it makes sense.
          >
          > I can't make sense of the idea of sizing tasks in story points. Should
          > all the task-story-points add up to the total size of the story? What
          > if you add a new task later on? I'd be very interested in hearing how
          > this system works, how it helps. My instinct is to dismiss it... but I
          > have made that mistake before (!) so now I seek enlightenment. Anyone?

          I agree that estimating tasks is wasteful, but it's helpful for many
          teams new to Agile and is not their biggest waste.

          When you really get going, though, I think it's best to have really
          small stories, such that you don't need to explicitly break them down
          into tasks at all. That requires developing the skill such that a story
          takes less than a day to complete.

          - George

          --
          ----------------------------------------------------------------------
          * George Dinwiddie * http://blog.gdinwiddie.com
          Software Development http://www.idiacomputing.com
          Consultant and Coach http://www.agilemaryland.org
          ----------------------------------------------------------------------
        • Tobias Mayer
          Hi George, I like the idea of getting stories down to such a small size, and indeed strive for it. It is tough! Ideally I d like to forget all about story
          Message 4 of 11 , Jan 30, 2008
          • 0 Attachment
            Hi George,

            I like the idea of getting stories down to such a small size, and indeed
            strive for it. It is tough! Ideally I'd like to forget all about story
            points, or any other measure of size or time and simply measure
            velocity in actual stories completed. When stories get small enough
            they will all be of an approximate same size anyway.

            Tobias

            --- In scrumdevelopment@yahoogroups.com, George Dinwiddie <lists@...>
            wrote:

            > I agree that estimating tasks is wasteful, but it's helpful for many
            > teams new to Agile and is not their biggest waste.
            >
            > When you really get going, though, I think it's best to have really
            > small stories, such that you don't need to explicitly break them down
            > into tasks at all. That requires developing the skill such that a
            story
            > takes less than a day to complete.
            >
            > - George
            >
            >
            > Tobias Mayer wrote:
            > >
            > > I recently heard that some CSM trainers are recommending that teams
            use
            > > story points to estimate the size of tasks. This baffles me. I
            think
            > > they are called story points for a reason: they are used to measure
            the
            > > relative size of stories.
            ...
          • Paul Oldfield
            (responding to Tobias) ... What worries me about this is the chunky stories that get on the backlog at low to medium priority. Would you break them up into
            Message 5 of 11 , Jan 30, 2008
            • 0 Attachment
              (responding to Tobias)

              > I like the idea of getting stories down to such a small size, and
              > indeed strive for it. It is tough! Ideally I'd like to forget
              > all about story points, or any
              > other measure of size or time and simply measure velocity
              > in actual stories completed. When stories get small enough
              > they will all be of an approximate same size anyway.

              What worries me about this is the 'chunky' stories that get
              on the backlog at low to medium priority. Would you break them
              up into small stories straight away, or would you forego
              any reasonably accurate forecast of how far you could get
              through the backlog by a particular date?

              ... or do you have a cunning plan ? ;-)

              Paul Oldfield
            • Tobias Mayer
              Hi Paul, In my experience release planning using big-chunk stories is so rough as to be no better than a wild guess. Sometimes worse. Most often, so many of
              Message 6 of 11 , Jan 30, 2008
              • 0 Attachment
                Hi Paul,

                In my experience release planning using big-chunk stories is so rough as
                to be no better than a wild guess. Sometimes worse. Most often, so
                many of those big stories, in fact so many stories of all sizes
                generally get dropped completely as the product develops, including
                those stories stakeholders are initially saying are absolute must-haves.

                My preference is to encourage POs to be date driven, releasing with the
                highest value stories, determined sprint by sprint.

                Project managers hate me ;-)

                Tobias


                --- In scrumdevelopment@yahoogroups.com, "Paul Oldfield"
                <PaulOldfield1@...> wrote:
                >
                > (responding to Tobias)
                >
                > > I like the idea of getting stories down to such a small size, and
                > > indeed strive for it. It is tough! Ideally I'd like to forget
                > > all about story points, or any
                > > other measure of size or time and simply measure velocity
                > > in actual stories completed. When stories get small enough
                > > they will all be of an approximate same size anyway.
                >
                > What worries me about this is the 'chunky' stories that get
                > on the backlog at low to medium priority. Would you break them
                > up into small stories straight away, or would you forego
                > any reasonably accurate forecast of how far you could get
                > through the backlog by a particular date?
                >
                > ... or do you have a cunning plan ? ;-)
                >
                > Paul Oldfield
                >
              • Mike Sutton
                Hi George, assuming that stories are the unit of exchange with the customer, doesn t that naturally mean that a story with more often than not have a number of
                Message 7 of 11 , Jan 31, 2008
                • 0 Attachment
                  Hi George,

                  assuming that stories are the unit of exchange with the customer,
                  doesn't that naturally mean that a story with more often than not have
                  a number of technical tasks to actually implement the story. These
                  tasks might increase depending on the team's definition of done
                  (design artefacts, unit tests, design etc)? So my argument against
                  stories so small they can't be broken down is that the customer value
                  can often get lost? Have you found this?

                  I do believe that breaking down into tasks is imperative for all but
                  the most ingrained team (worked with the process and domain for
                  years!!!), I see some value in young teams estimating tasks in hours
                  (my views on the benefits that some sort of task estimation outweighs
                  its waste have been expressed elsewhere :) ) but.

                  I am totally with Tobias on the Story to Done is the mark of
                  completion thing (a house isn't done, just cos the plumbing is in...is
                  it?) So now agro there.

                  If we view task estimates as a tool to manage expectation - with a
                  estimating directive that they are accurate given our current
                  understand and not precise - then they are really valuable.

                  I'll go back to sleep now.

                  mike
                  csm.csp.cspo.certified.certifiable.

                  --- In scrumdevelopment@yahoogroups.com, "Tobias Mayer" <tobyanon@...>
                  wrote:
                  >
                  > Hi George,
                  >
                  > I like the idea of getting stories down to such a small size, and indeed
                  > strive for it. It is tough! Ideally I'd like to forget all about story
                  > points, or any other measure of size or time and simply measure
                  > velocity in actual stories completed. When stories get small enough
                  > they will all be of an approximate same size anyway.
                  >
                  > Tobias
                  >
                  > --- In scrumdevelopment@yahoogroups.com, George Dinwiddie <lists@>
                  > wrote:
                  >
                  > > I agree that estimating tasks is wasteful, but it's helpful for many
                  > > teams new to Agile and is not their biggest waste.
                  > >
                  > > When you really get going, though, I think it's best to have really
                  > > small stories, such that you don't need to explicitly break them down
                  > > into tasks at all. That requires developing the skill such that a
                  > story
                  > > takes less than a day to complete.
                  > >
                  > > - George
                  > >
                  > >
                  > > Tobias Mayer wrote:
                  > > >
                  > > > I recently heard that some CSM trainers are recommending that teams
                  > use
                  > > > story points to estimate the size of tasks. This baffles me. I
                  > think
                  > > > they are called story points for a reason: they are used to measure
                  > the
                  > > > relative size of stories.
                  > ...
                  >
                • George Dinwiddie
                  ... I don t follow what you re saying. I may do a number of tasks to implement a story. Indeed, I could call each keypress a task, if I wanted to do so,
                  Message 8 of 11 , Jan 31, 2008
                  • 0 Attachment
                    Mike Sutton wrote:
                    > Hi George,
                    >
                    > assuming that stories are the unit of exchange with the customer,
                    > doesn't that naturally mean that a story with more often than not have
                    > a number of technical tasks to actually implement the story. These
                    > tasks might increase depending on the team's definition of done
                    > (design artefacts, unit tests, design etc)? So my argument against
                    > stories so small they can't be broken down is that the customer value
                    > can often get lost? Have you found this?

                    I don't follow what you're saying. I may do a number of tasks to
                    implement a story. Indeed, I could call each keypress a task, if I
                    wanted to do so, without violating the definition of task.

                    So, stories always *could* be broken down into a list of tasks and are,
                    indeed, accomplished by doing tasks. I just don't find the creation of
                    that list of tasks to be valuable in itself. People often do it because
                    they don't want to forget any of them. Usually that's because they have
                    a large list of tasks--and that's usually because the story is rather
                    large and accomplishes several things. At least, that's my experience.

                    I'm not sure what you mean about the customer value getting lost.

                    > I do believe that breaking down into tasks is imperative for all but
                    > the most ingrained team (worked with the process and domain for
                    > years!!!), I see some value in young teams estimating tasks in hours
                    > (my views on the benefits that some sort of task estimation outweighs
                    > its waste have been expressed elsewhere :) ) but.

                    Until you've worked with stories that are small enough to accomplish
                    just from an acceptance test, then a list of tasks seems very necessary
                    and valuable. I don't think that reaching this capability is as
                    difficult as you describe.

                    > If we view task estimates as a tool to manage expectation - with a
                    > estimating directive that they are accurate given our current
                    > understand and not precise - then they are really valuable.

                    Whose expectation are you managing? What expectation is that?

                    - George

                    --
                    ----------------------------------------------------------------------
                    * George Dinwiddie * http://blog.gdinwiddie.com
                    Software Development http://www.idiacomputing.com
                    Consultant and Coach http://www.agilemaryland.org
                    ----------------------------------------------------------------------
                  • Mike Sutton
                    Bear with me whilst I explain by example... There is a story: As a book shopper, I want to search for books by ISBN ... This is what the customer knows and
                    Message 9 of 11 , Feb 1, 2008
                    • 0 Attachment
                      Bear with me whilst I explain by example...

                      There is a story:
                      'As a book shopper, I want to search for books by ISBN'...
                      This is what the customer knows and wants -
                      The team says this story is a 3 pointer.

                      So the team (one person/a pair - whatever) picks up the story and
                      break it down to tech tasks (keypresses don't count!) - to make sure
                      they cover the bases etc

                      This is for a web appplication, so they identify the tasks as:

                      a screen to be designed to take the search;
                      one screen for the results
                      a database query to be written
                      some indexes to create on the database
                      and all the glue inbetween. The team also has additional tasks to do
                      as part of 'done' (unit tests, a sequence diagram to cement their
                      understanding of the required flow). These always have to happen (not
                      all but they have to go through the thought process) so maybe don't
                      have to be explicitly listed.

                      Infact, these are the same elements of the story that the team
                      mentioned when trying to estimate the story.

                      During the story planning with the developer, tester and PO - the
                      tester asks 'what do you think you might do first, when do you think
                      the screen would be ready for me to have a look at' etc, to which the
                      developer gives rough hour based estimates.

                      The key to my point is that if we as individuals internally logically
                      use tasks to size stories and use hours in estimating tasks
                      informally, let us have visibility of that in the process. And just
                      like the prime directive, let it be known that they are ESTIMATES!

                      I don't want to see stories from the customer like

                      'I want a databse query for ISBN search' or 'I want an index on
                      BOOK_ISBN' - I suspect that the customer does not know or care about this.

                      To me this is a symptom of a product owner on too much techie juice!

                      Anyway - ramble over - thanks for sticking with me this far :), this
                      thread has helped me galvanise various ideas in my head to try with my
                      teams.

                      mike.
                      csm.csp.csp.certified.certifiable.
                    • George Dinwiddie
                      ... Depending on the context, that could be a really small story or it could be a large epic. If it is an epic, one way of handling the problem is to slice it
                      Message 10 of 11 , Feb 1, 2008
                      • 0 Attachment
                        Mike Sutton wrote:
                        > Bear with me whilst I explain by example...
                        >
                        > There is a story:
                        > 'As a book shopper, I want to search for books by ISBN'...

                        Depending on the context, that could be a really small story or it could
                        be a large epic. If it is an epic, one way of handling the problem is
                        to slice it into thin, vertical slices, each of which has business value.

                        > This is for a web appplication, so they identify the tasks as:
                        >
                        > a screen to be designed to take the search;
                        > one screen for the results
                        > a database query to be written
                        > some indexes to create on the database
                        > and all the glue inbetween. The team also has additional tasks to do
                        > as part of 'done' (unit tests, a sequence diagram to cement their
                        > understanding of the required flow). These always have to happen (not
                        > all but they have to go through the thought process) so maybe don't
                        > have to be explicitly listed.

                        OK, so you're telling me that, in this context,
                        - there is no existing search screen
                        - there is no existing results screen
                        - probably there is no existing search functionality at all

                        On that assumption, I'd say this is an epic. Is this an accurate
                        reading of the context?

                        > I don't want to see stories from the customer like
                        >
                        > 'I want a databse query for ISBN search' or 'I want an index on
                        > BOOK_ISBN' - I suspect that the customer does not know or care about this.

                        Nor do I. I don't consider those to be user stories.

                        You've propose two alternatives.
                        - A big story with quite a number of good-sized tasks that must be
                        estimated separately to get an ideal of how long the story will take to
                        accomplish, or
                        - Calling each of those good-sized tasks a story, and doing the same
                        thing.

                        Having only two alternatives is a dilemma. Can you think of a third?

                        - George

                        --
                        ----------------------------------------------------------------------
                        * George Dinwiddie * http://blog.gdinwiddie.com
                        Software Development http://www.idiacomputing.com
                        Consultant and Coach http://www.agilemaryland.org
                        ----------------------------------------------------------------------
                      • Tony
                        I know this has been heavily discussed but I wanted to throw my 2 cents in as well. On our team, we are still learning the basis of formulating story points
                        Message 11 of 11 , Feb 1, 2008
                        • 0 Attachment
                          I know this has been heavily discussed but I wanted to throw my 2
                          cents in as well. On our team, we are still learning the basis of
                          formulating story points for our *stories* heh, estimating our tasks
                          is basically boiled down to making sure each task is held under a
                          day.

                          I see the importance of being able to develop proper story points to
                          gauge an idea of a long term plan but for tasks, at least in our
                          case, we like to have hour estimates because it keeps everyone in
                          the proper mindset that they want to see the blue bars go down and
                          the green bars go up.

                          Just having our burn-down, burn-up charts in our team room provided
                          the team with a way of , keeping focused on our new process and not
                          let any old habits or mentality slip back in.

                          While still new, I think we are learning slowly.



                          --- In scrumdevelopment@yahoogroups.com, "Tobias Mayer"
                          <tobyanon@...> wrote:
                          >
                          >
                          > I recently heard that some CSM trainers are recommending that
                          teams use
                          > story points to estimate the size of tasks. This baffles me. I
                          think
                          > they are called story points for a reason: they are used to
                          measure the
                          > relative size of stories.
                          >
                          > I don't encourage teams to estimate task size at all except to
                          ensure
                          > that a task is small enough to move from "In Progress" to "Done"
                          in a
                          > single day, but I understand that some teams successfully use real
                          time
                          > (i.e. hours) to estimate task size. I think it is an unnecessary,
                          > perhaps even wasteful practice, but at least it makes sense.
                          >
                          > I can't make sense of the idea of sizing tasks in story points.
                          Should
                          > all the task-story-points add up to the total size of the story?
                          What
                          > if you add a new task later on? I'd be very interested in
                          hearing how
                          > this system works, how it helps. My instinct is to dismiss it...
                          but I
                          > have made that mistake before (!) so now I seek enlightenment.
                          Anyone?
                          >
                          > Cheers.
                          > Tobias
                          > http://agilethinking.net <http://agilethinking.net>
                          >
                        Your message has been successfully submitted and would be delivered to recipients shortly.