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

Re: using story points to estimate tasks

Expand Messages
  • 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 1 of 11 , Feb 1, 2008
      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 2 of 11 , Feb 1, 2008
        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 3 of 11 , Feb 1, 2008
          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.