Submitted by MichaelJames on May 20, 2008 - 4:53pm.
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.
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
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