## Re: [XP] User Stories

Expand Messages
• ... Yes I have a fixed number of ideal days for each complexity level. The translation of complexity to ideal days is defined initially by either through past
Message 1 of 74 , May 31, 2003
• 0 Attachment
> large complexity" sounds similar to a 1-2-3 point approach, but
> you then translate complexity into ideal days. Do you have a
> fixed number of ideal days for each complexity level? Are you
> deriving numbers from past experience? How does this approach
> avoid story estiamtes not being in proportion?

Yes I have a fixed number of ideal days for each complexity level. The
translation of complexity to ideal days is defined initially by either
through past experience or gut feel if its a new team. One of the goal of
this approach is to have the developers not thinking in days but in relative
complexities between story cards. This avoids the situation where developers
pad days when estimating. Another benefit is avoid situations where a
developer can't decide between 4 or 5 ideal days which really does not
matter. I found using 1-2-3 point approach does not work because complexity
to ideal days is not a linear translation. Important to note that we monitor
how accurate our translation estimates are and reestimate as needed.

Here's what we do during an estimation meeting
1. We start by picking the first few story cards and dropping them into
different complexity buckets (Gut Feel Estimate)
2. As we go through each story card, we compare it with the story cards
already in the buckets and drop it into a similar complexity bucket.
(Estimate by analogy)
3. We might also move some of the story cards estimated early to the
appropriate bucket if we think they are not quite right.
4. If we find story cards that are too complexity we get the customer to
help us break it down to chucks. (Estimate by decomposition)
5. Final outcome - all story cards are place into the appropriate complexity
buckets.
6. We then define the translation by past experience or gut feel if its a
new team.

Here are a list of Complexities we are current using
Complexity Ideal days
Very Small 0.5
Small 2
Medium 4
Large 7.5
Very Large 12
Rocket Science 20

Regards

Michael Lee
Thoughtworks.com
• ... It seems OK to me, you seem to know what s accurate, what s not, and how to transform from not to accurate. If the customer is OK with not having a solid
Message 74 of 74 , Jun 2, 2003
• 0 Attachment
On Monday, June 2, 2003, at 5:09:38 PM, Michael Lee wrote:

> Ron

>> I find that some people want to know how much will be done by when on most
>> projects. If your "big story" estimates are inaccurate, wouldn't that make
>> it hard to answer that kind of question?
> Yes that's true. The customer has been given the expectation that the more
> complex story cards are more inaccurate. We are happy to make it more
> accurate and break it down if they really care about it but they need to
> plan it into an iteration for us to spike it and do more analyst on it :-)

>> How are you managing to get around, past, or through that kind of concern?

> We are managing the customer expectation by having him sit with us in the
> development area, being honest with the customer, ensuring that he
> understand if he wants more accurate estimates he will be reducing team
> velocity but its his call and we keep close track of estimate at completion
> in ideal days of the project for the current release (ie. monitor any
> movements).

> What do you think of the way I have gone about estimating so far ?

It seems OK to me, you seem to know what's accurate, what's not, and how to
transform from not to accurate.

If the customer is OK with not having a solid big picture, that's great.
I've just so rarely seen them be comfortable with not seeing the end.

Keep us posted!

Ron Jeffries
www.XProgramming.com
The opinions expressed here /are/ necessarily those of XProgramming.com.
But I might change my mind.
Your message has been successfully submitted and would be delivered to recipients shortly.