Danube - What do Story Points represent? - Comments

wow gold

ssqt — Fri, 11 Jul 2008 01:23:41 -0500

wow gold wow gold wow gold Age of Conan gold cheap wow gold are all in gamelee.

You've Changed my mind...

Dan Rawsthorne — Tue, 20 May 2008 22:42:08 -0500

mj, you've made me change my mind. I still think that "a mile is a mile", but now agree that the mile we're talking about is a mile in the idealized problem space. That is, we ask "how far is it, given a 'normal' definition of done, a good codebase to work, and your team working at its best?"

Maybe we've finally reached agreement... I hope so.

Dan ;-)

Dan Rawsthorne, PhD, CST
Transformation Coach
http://www.danube.com

when a mile isn't a mile

MichaelJames — Tue, 20 May 2008 19:53:46 -0500

Dan and I had some follow up discussion that's worth posting here.

For me there's nothing analogous to a "mile" in the problem space, only in the solution space. And the solution space is more than one-dimensional because different teams will invent different solutions paths to the same problems. This is independent of how fast they can run down those paths (velocity). A team that's generally slower than another might know a shortcut for a particular story. This is part of why Dan and I insist on teams estimating their own work.

One team might implement the solution using third party libraries, another with some regexp magic, someone else by coding the whole thing from scratch. The "intrinsic difficulty" of a problem is a nonexistent thing which (in my opinion) isn't as useful to consider without a gut feel guess about the solution.

However, this doesn't mean we need a detailed plan for the solution to give our gut feel effort estimate. In fact there's some evidence that overanalyzing leads to *worse* guesses than underanalyzing.

To make matters worse, most of the work we do creating products isn't the creative design and programming we enjoy. A lot of it is

talking to customers to tease out what they really need,
getting the development tools and libraries to do what they're supposed to do,
finding workarounds for limitations of other people's stuff we can't change (e.g. database servers, web browsers, hardware),
chasing down phantom regression failures from our imperfect test harnesses,
etc.

In my experience the variation of these things from story to story comprises the bulk of the differences in estimates! A "complex" story that can be implemented mostly on the server side could take less time and effort than a "simple" story that entails getting a page to render nicely on multiple buggy versions of Internet Explorer. Some work exacts a higher effort cost from the team by virtue of being more annoying to do.

In practice, Dan and I agree it comes down to gut feel. Your team's intuition may not be enough, but it's all you've got.

--mj

well, yeah

MichaelJames — Tue, 20 May 2008 14:32:17 -0500

That's true, though we prefer to use relative points for estimating Product Backlog Items (stories), then hours for estimating the (1 day-ish) tasks we break stories into for Sprint execution.

--mj

solution

consultanta it — Sun, 18 May 2008 19:32:31 -0500

Story points are units of relative size used in estimating tasks in agile software development.

What do Story Points represent?

Dan Rawsthorne — Wed, 5 Mar 2008 12:32:03 -0600

So, since we are astute enough so that we're not expecting a story’s size (In Story Points) to be an accurate reflection of the effort it takes for the story – even though we expect a correlation on average – what is our expectation of what a story’s size reflects?