Re: using story points to estimate tasks
- 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
- Mike Sutton wrote:
> Bear with me whilst I explain by example...Depending on the context, that could be a really small story or it could
> There is a story:
> 'As a book shopper, I want to search for books by ISBN'...
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:OK, so you're telling me that, in this context,
> 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.
- 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 likeNor do I. I don't consider those to be user stories.
> '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.
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
- Calling each of those good-sized tasks a story, and doing the same
Having only two alternatives is a dilemma. Can you think of a third?
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
- 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
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 firstname.lastname@example.org, "Tobias Mayer"
> I recently heard that some CSM trainers are recommending that
> story points to estimate the size of tasks. This baffles me. Ithink
> they are called story points for a reason: they are used tomeasure the
> relative size of stories.ensure
> I don't encourage teams to estimate task size at all except to
> 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 realtime
> (i.e. hours) to estimate task size. I think it is an unnecessary,Should
> perhaps even wasteful practice, but at least it makes sense.
> I can't make sense of the idea of sizing tasks in story points.
> 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 inhearing 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?
> http://agilethinking.net <http://agilethinking.net>