## Complexity X Time

Expand Messages
• Hi people! It s been very hard for me to separate complexity and time when we re planning a sprint. I see them too close. I mean, if a story is too complex, it
Message 1 of 17 , Jun 30, 2010
Hi people!

It's been very hard for me to separate complexity and time when we're planning a sprint. I see them too close. I mean, if a story is too complex, it means the team spend more time to complete this story.

Within the first Schwaber book about Scrum, he does not mention Story Points or Planning Poker or Fibonacci. Just time (hours and days). Why do we need to estimate the complexity, and not just the time?

Best regards!
• On Wed, Jun 30, 2010 at 9:43 PM, Rafael Nascimento
Message 2 of 17 , Jun 30, 2010
On Wed, Jun 30, 2010 at 9:43 PM, Rafael Nascimento wrote:

Hi people!

It's been very hard for me to separate complexity and time when we're planning a sprint. I see them too close. I mean, if a story is too complex, it means the team spend more time to complete this story.

In fact if you read Mike Cohn's recent blog post on the subject and a thread either on this list or the Scrum Alliance list - you don't. Story Points are intended to measure effort. I.E. the time the team members believe it will take.

Within the first Schwaber book about Scrum, he does not mention Story Points or Planning Poker or Fibonacci. Just time (hours and days). Why do we need to estimate the complexity, and not just the time?

Estimates of absolute time decay have numerous problems:
- How long will it take you to leave the office, pickup the kids, go to the grocery store and pickup your spouses cleaning. Please provide a precise estimate of when you will be home. Hmmmm you arrived 30 minutes later than the estimate, why? were you lazy? ...
- As the team improves over time estimates in ideal days will decay - i.e. the team gets faster (or even automates) certain tasks, now the original estimates for the related stories no longer hold.

There are heaps more reasons, but I'm tired and have to facilitate an Innovation Games session tomorrow.

Cheers
Mark
 Mark Levison | Agile Pain Relief Consulting | Agile Editor @ InfoQBlog | Twitter | Office: (613) 862-2538Recent Entries: Self Inflicted Agile Injuries, Why use an Agile Coach

Best regards!

• Story points are meant to be a measurement of effort and not complexity. Mike Cohn actually blogged about this just over a week ago
Message 3 of 17 , Jun 30, 2010
Story points are meant to be a measurement of effort and not
(http://blog.mountaingoatsoftware.com/its-effort-not-complexity)

The notion of estimating complexity is one of the things that was
experimented with in the early days of XP (Gummy Bears... I couldn't
find a good reference), but it is difficult to use effectively.
Complexity doesn't correlate strongly to time, as Mike illustrates
with his analogy (licking 1,000 stamps vs. performing brain surgery.)

If you are measuring velocity, and you want that measurement to be
stable enough to be useful, then you need something that is roughly
comparable to time. The best thing (besides ignoring velocity, which
is what I actually recommend) is stories of roughly comparable size so
that velocity is the number of stories done per iteration averaged out
over a period of time. The next best thing is story points that
roughly correlate to same vague idea of relative effort, because
effort is comparable to time.

On Wed, Jun 30, 2010 at 6:43 PM, Rafael Nascimento
<rafaelnascimento.rj@...> wrote:
>
>
>
> Hi people!
>
> It's been very hard for me to separate complexity and time when we're planning a sprint. I see them too close. I mean, if a story is too complex, it means the team spend more time to complete this story.
>
> Within the first Schwaber book about Scrum, he does not mention Story Points or Planning Poker or Fibonacci. Just time (hours and days). Why do we need to estimate the complexity, and not just the time?
>
> Best regards!
>
>
• P.S. the reason Schwaber didn t write anything about story points is that they weren t a part of Scrum (neither were stories.) These ideas come from XP. Mike
Message 4 of 17 , Jun 30, 2010
P.S. the reason Schwaber didn't write anything about story points is that they weren't a part of Scrum (neither were stories.) These ideas come from XP. Mike Cohn popularized them with his book and many Scrum teams subsequently adopted them. Unfortunately, many Scrum teams seem to have conflated ideas from the XP planning game with Scrum's description of Sprint/Release planning in a way that dilutes the effectiveness of either approach (e.g. creating "technical stories" or assuming that all work that has to be done must be sized in points.)

On Wed, Jun 30, 2010 at 6:43 PM, Rafael Nascimento wrote:

Hi people!

It's been very hard for me to separate complexity and time when we're planning a sprint. I see them too close. I mean, if a story is too complex, it means the team spend more time to complete this story.

Within the first Schwaber book about Scrum, he does not mention Story Points or Planning Poker or Fibonacci. Just time (hours and days). Why do we need to estimate the complexity, and not just the time?

Best regards!

• Hi guys! So I was completely wrong in my thinking, and I m really sorry for that! Actually, our sprint planning meeting was showing me that story points as
Message 5 of 17 , Jun 30, 2010
Hi guys!

So I was completely wrong in my thinking, and I'm really sorry for that!

Actually, our sprint planning meeting was showing me that story points as complexity were making the team struggle a lot, and our planning was getting too long because of this.

A just read Cohn's post, and he was enfatic: story points are about effort, and effort is about time.

Thanks!

P.S. the reason Schwaber didn't write anything about story points is that they weren't a part of Scrum (neither were stories.) These ideas come from XP. Mike Cohn popularized them with his book and many Scrum teams subsequently adopted them. Unfortunately, many Scrum teams seem to have conflated ideas from the XP planning game with Scrum's description of Sprint/Release planning in a way that dilutes the effectiveness of either approach (e.g. creating "technical stories" or assuming that all work that has to be done must be sized in points.)

On Wed, Jun 30, 2010 at 6:43 PM, Rafael Nascimento wrote:

Hi people!

It's been very hard for me to separate complexity and time when we're planning a sprint. I see them too close. I mean, if a story is too complex, it means the team spend more time to complete this story.

Within the first Schwaber book about Scrum, he does not mention Story Points or Planning Poker or Fibonacci. Just time (hours and days). Why do we need to estimate the complexity, and not just the time?

Best regards!

• On Wed, Jun 30, 2010 at 7:44 PM, Rafael Nascimento ... Don t be sorry. Like I said, early XP adopters tried this idea too, and a lot of them were really smart
Message 6 of 17 , Jun 30, 2010
On Wed, Jun 30, 2010 at 7:44 PM, Rafael Nascimento
<rafaelnascimento.rj@...> wrote:
>
>
>
> Hi guys!
>
> So I was completely wrong in my thinking, and I'm really sorry for that!
>

Don't be sorry. Like I said, early XP adopters tried this idea too,
and a lot of them were really smart guys. Unfortunately, it just
doesn't work that well, as you have observed.

> Actually, our sprint planning meeting was showing me that story points as complexity were making the team struggle a lot, and our planning was getting too long because of this.
>

Yep. That's what I have seen too. Incidentally, the same is true of
estimating effort, or ideal time. Teams seem to spend more time on
estimation than any other single activity which does not contribute to
actual working software. This might lead you to conclude that they
would get more done if they just didn't estimate. In fact, this
appears to be true almost universally (Based on my own experience with
teams and conversations I've had with peers and mentors.) This
realization has led some teams not to estimate, or to do so on an as
needed basis rather than as a matter of course (e.g. give a rough
estimate for a large customer request, but don't estimate at the
beginning of every iteration.)

> A just read Cohn's post, and he was enfatic: story points are about effort, and effort is about time.
>

• On Wed, Jun 30, 2010 at 10:56 PM, Adam Sroka wrote: Yep. That s what I have seen too. Incidentally, the same is true of ... I ve not met
Message 7 of 17 , Jun 30, 2010
On Wed, Jun 30, 2010 at 10:56 PM, Adam Sroka wrote:

Yep. That's what I have seen too. Incidentally, the same is true of
estimating effort, or ideal time. Teams seem to spend more time on
estimation than any other single activity which does not contribute to
actual working software. This might lead you to conclude that they
would get more done if they just didn't estimate. In fact, this
appears to be true almost universally (Based on my own experience with
teams and conversations I've had with peers and mentors.) This
realization has led some teams not to estimate, or to do so on an as
needed basis rather than as a matter of course (e.g. give a rough
estimate for a large customer request, but don't estimate at the
beginning of every iteration.)

I've not met Adam so can claim to be neither a mentor or peer. However my experience chimes with his. Estimation is a waste. Estimation of tasks in hours is utter waste, people spend hours debating minutia, when they would better off just starting. Even estimation of stories in points is a waste, however to make your projects progress predictable and transparent this requires that stories be roughly the same size +/- one Delta. For most teams (mature or not) this turns out to be difficult, so they stick to story points.

Time for sleep
Mark
 Mark Levison | Agile Pain Relief Consulting | Agile Editor @ InfoQBlog | Twitter | Office: (613) 862-2538Recent Entries: Self Inflicted Agile Injuries, Why use an Agile Coach

• Hello, Rafael. On Wednesday, June 30, 2010, at 9:43:07 PM, you ... You don t. In fact, you don t really even need to estimate at all. But if you do, what
Message 8 of 17 , Jun 30, 2010
Hello, Rafael. On Wednesday, June 30, 2010, at 9:43:07 PM, you
wrote:

> Within the first Schwaber book about Scrum, he does not mention Story Points
> or Planning Poker or Fibonacci. Just time (hours and days). Why do we need
> to estimate the complexity, and not just the time?

You don't. In fact, you don't really even need to estimate at all.
But if you do, what you're trying to derive is time.

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
Do as you will, try to do it well. That's what I do.
• Ron, don t need to estimate complexity or don t need to estimate *anything* at all?
Message 9 of 17 , Jun 30, 2010
Ron,

don't need to estimate complexity or don't need to estimate *anything* at all?

On Thu, Jul 1, 2010 at 12:09 AM, Ron Jeffries wrote:

Hello, Rafael. On Wednesday, June 30, 2010, at 9:43:07 PM, you
wrote:

> Within the first Schwaber book about Scrum, he does not mention Story Points
> or Planning Poker or Fibonacci. Just time (hours and days). Why do we need
> to estimate the complexity, and not just the time?

You don't. In fact, you don't really even need to estimate at all.
But if you do, what you're trying to derive is time.

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
Do as you will, try to do it well. That's what I do.

• ... True, but I can imagine a highly functioning organization able to have the following conversation: Boss: We have this really big thing we d like you to
Message 10 of 17 , Jun 30, 2010
On Wed, Jun 30, 2010 at 8:02 PM, Mark Levison <mark@...> wrote:
>
>
> I've not met Adam so can claim to be neither a mentor or peer. However my experience chimes with his. Estimation is a waste. Estimation of tasks in hours is utter waste, people spend hours debating minutia, when they would better off just starting. Even estimation of stories in points is a waste, however to make your projects progress predictable and transparent this requires that stories be roughly the same size +/- one Delta. For most teams (mature or not) this turns out to be difficult, so they stick to story points.

True, but I can imagine a highly functioning organization able to have
the following conversation:

Boss: "We have this really big thing we'd like you to do. What do you
think it'll take?"

Team: "We've done some other big things that aren't entirely different
from that thing, and they took an average of about six months. So,
we're thinking it'll take between four and eight months to get it all
into production."

Boss: "Great! I know that it costs about \$50K to keep you guys running
for a month. That means that this is going to cost me about \$200-400K.
Based on what we know of the market that should be well worth it. When
will you have something to show us?"

Team: "In about a week, but before we start let's sit down and write
some user stories so that we can prioritize them and get a better feel
for what the first pieces of functionality will be."
• ... Hmmmm, I ve never seen an organization like that. When you find one I want to visit as anthropologist, as I doubt I would have much to coach there. Cheers
Message 11 of 17 , Jun 30, 2010
On Wed, Jun 30, 2010 at 11:19 PM, Adam Sroka wrote:

True, but I can imagine a highly functioning organization able to have
the following conversation:

Boss: "We have this really big thing we'd like you to do. What do you
think it'll take?"

Team: "We've done some other big things that aren't entirely different
from that thing, and they took an average of about six months. So,
we're thinking it'll take between four and eight months to get it all
into production."

Boss: "Great! I know that it costs about \$50K to keep you guys running
for a month. That means that this is going to cost me about \$200-400K.
Based on what we know of the market that should be well worth it. When
will you have something to show us?"

Team: "In about a week, but before we start let's sit down and write
some user stories so that we can prioritize them and get a better feel
for what the first pieces of functionality will be."

Hmmmm, I've never seen an organization like that. When you find one I want to visit as anthropologist, as I doubt I would have much to coach there.

Cheers
Mark
 Mark Levison | Agile Pain Relief Consulting | Agile Editor @ InfoQBlog | Twitter | Office: (613) 862-2538Recent Entries: Self Inflicted Agile Injuries, Why use an Agile Coach
• ... I ve not quite gotten there yet either, but I ve seen glimpses. Besides, it s good to have something to strive for ;-)
Message 12 of 17 , Jun 30, 2010
On Wed, Jun 30, 2010 at 8:22 PM, Mark Levison <mark@...> wrote:
>
>
>
> On Wed, Jun 30, 2010 at 11:19 PM, Adam Sroka <adam.sroka@...> wrote:
>>
>> True, but I can imagine a highly functioning organization able to have
>> the following conversation:
>>
>> Boss: "We have this really big thing we'd like you to do. What do you
>> think it'll take?"
>>
>> Team: "We've done some other big things that aren't entirely different
>> from that thing, and they took an average of about six months. So,
>> we're thinking it'll take between four and eight months to get it all
>> into production."
>>
>> Boss: "Great! I know that it costs about \$50K to keep you guys running
>> for a month. That means that this is going to cost me about \$200-400K.
>> Based on what we know of the market that should be well worth it. When
>> will you have something to show us?"
>>
>> Team: "In about a week, but before we start let's sit down and write
>> some user stories so that we can prioritize them and get a better feel
>> for what the first pieces of functionality will be."
>
> Hmmmm, I've never seen an organization like that. When you find one I want to visit as anthropologist, as I doubt I would have much to coach there.

I've not quite gotten there yet either, but I've seen glimpses.
Besides, it's good to have something to strive for ;-)
• LOL!
Message 13 of 17 , Jun 30, 2010
LOL!

On Thu, Jul 1, 2010 at 12:22 AM, Mark Levison <mark@...> wrote:

On Wed, Jun 30, 2010 at 11:19 PM, Adam Sroka wrote:

True, but I can imagine a highly functioning organization able to have
the following conversation:

Boss: "We have this really big thing we'd like you to do. What do you
think it'll take?"

Team: "We've done some other big things that aren't entirely different
from that thing, and they took an average of about six months. So,
we're thinking it'll take between four and eight months to get it all
into production."

Boss: "Great! I know that it costs about \$50K to keep you guys running
for a month. That means that this is going to cost me about \$200-400K.
Based on what we know of the market that should be well worth it. When
will you have something to show us?"

Team: "In about a week, but before we start let's sit down and write
some user stories so that we can prioritize them and get a better feel
for what the first pieces of functionality will be."

Hmmmm, I've never seen an organization like that. When you find one I want to visit as anthropologist, as I doubt I would have much to coach there.

Cheers
Mark
 Mark Levison | Agile Pain Relief Consulting | Agile Editor @ InfoQBlog | Twitter | Office: (613) 862-2538Recent Entries: Self Inflicted Agile Injuries, Why use an Agile Coach

• ... Another important point -- you have to be able to think mathematically to get this, but hopefully everyone can follow: Mike Cohn says that we should
Message 14 of 17 , Jun 30, 2010
On Wed, Jun 30, 2010 at 8:02 PM, Mark Levison <mark@...> wrote:
>
> I've not met Adam so can claim to be neither a mentor or peer. However my experience chimes with his. Estimation is a waste. Estimation of tasks in hours is utter waste, people spend hours debating minutia, when they would better off just starting. Even estimation of stories in points is a waste, however to make your projects progress predictable and transparent this requires that stories be roughly the same size +/- one Delta. For most teams (mature or not) this turns out to be difficult, so they stick to story points.

Another important point -- you have to be able to think mathematically
to get this, but hopefully everyone can follow:

Mike Cohn says that we should estimate relative sizes within an order
of magnitude, because more than that is hard for our brains to keep
track of. He also says that we should avoid adjacent numbers and use
either a Fibonacci sequence or powers of two.

That means that our numbers are distributed across a single order of
magnitude about logarithmically. Statistically, this variation becomes
insignificant after only a few iterations.

So, if numbers are evenly distributed among stories the average is
about 4 (for the set [1, 2, 3, 5, 8] the mean is 3.8 and for the set
[1, 2, 4, 8] the mean is 3.75) If you divide story points by that
average it should approximately equal the number of stories you did
within some small margin of error.

That, of course, assumes that your team evenly distributes it's
estimates. Most do not. For most you could look through about three to
five iterations, pick the number that occurs most often, and divide by
that. You should still get pretty close (Try it!)

So, if you estimate the way Mike Cohn recommends you should be just
about as accurate as if you just counted the number of stories.
Estimates are not statistically significant if done as recommended
(And, I submit that an attempt to make them significant would also
make them less accurate for the reasons that Mike explains -- adjacent
numbers are hard to differentiate and wide ranges of choices are hard
to apply consistently.)
• P.P.S. I do not mean to imply anything about Mike Cohn s intelligence here. I did it his way for years before I figured this out. I have learned a lot from
Message 15 of 17 , Jun 30, 2010
P.P.S. I do not mean to imply anything about Mike Cohn's intelligence
here. I did it his way for years before I figured this out. I have
learned a lot from him.

On Wed, Jun 30, 2010 at 9:02 PM, Adam Sroka <adam.sroka@...> wrote:
> On Wed, Jun 30, 2010 at 8:02 PM, Mark Levison <mark@...> wrote:
>>
>> I've not met Adam so can claim to be neither a mentor or peer. However my experience chimes with his. Estimation is a waste. Estimation of tasks in hours is utter waste, people spend hours debating minutia, when they would better off just starting. Even estimation of stories in points is a waste, however to make your projects progress predictable and transparent this requires that stories be roughly the same size +/- one Delta. For most teams (mature or not) this turns out to be difficult, so they stick to story points.
>
>
> Another important point -- you have to be able to think mathematically
> to get this, but hopefully everyone can follow:
>
> Mike Cohn says that we should estimate relative sizes within an order
> of magnitude, because more than that is hard for our brains to keep
> track of. He also says that we should avoid adjacent numbers and use
> either a Fibonacci sequence or powers of two.
>
> That means that our numbers are distributed across a single order of
> magnitude about logarithmically. Statistically, this variation becomes
> insignificant after only a few iterations.
>
> So, if numbers are evenly distributed among stories the average is
> about 4 (for the set [1, 2, 3, 5, 8] the mean is 3.8 and for the set
> [1, 2, 4, 8] the mean is 3.75) If you divide story points by that
> average it should approximately equal the number of stories you did
> within some small margin of error.
>
> That, of course, assumes that your team evenly distributes it's
> estimates. Most do not. For most you could look through about three to
> five iterations, pick the number that occurs most often, and divide by
> that. You should still get pretty close (Try it!)
>
> So, if you estimate the way Mike Cohn recommends you should be just
> about as accurate as if you just counted the number of stories.
> Estimates are not statistically significant if done as recommended
> (And, I submit that an attempt to make them significant would also
> make them less accurate for the reasons that Mike explains -- adjacent
> numbers are hard to differentiate and wide ranges of choices are hard
> to apply consistently.)
>
• Hello, Heitor. On Wednesday, June 30, 2010, at 11:18:36 PM, you ... If you want to estimate, estimate time. If you don t want to estimate, there is no real
Message 16 of 17 , Jun 30, 2010
Hello, Heitor. On Wednesday, June 30, 2010, at 11:18:36 PM, you
wrote:

> don't need to estimate complexity or don't need to estimate *anything* at
> all?

If you want to estimate, estimate time. If you don't want to
estimate, there is no real need to do so.

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
It is a bad plan that admits of no modifications. -- Publius Syrus (ca. 42 BCE)
• Adam & Mark, I find the estimating of stories and tasks done with a light touch is no a waste, but rather a communication of expectations. For Stories, using
Message 17 of 17 , Jul 1, 2010

I find the estimating of stories and tasks done with a light touch is no a waste, but rather a communication of expectations.

For Stories, using Mike Cohn's guidance on numerical estimating, I find setting the expectation that it should no more accurate than the metaphor of t-shirt sizes: S, M, L, XL (XXL?) that frees people to have a quick consensus on what's being committed to when a team takes on a story.

For tasks, also using a light touch, it's a quick and easy step to communicate evolving expectations that can be changed on the fly as learning takes place. This informs transparent communication to all stakeholders of the sate of an iteration.

I find that Adam's scenario is exactly what I encourage for my clients. It starts with acknowledging what's known and not known. This also resembles my advice to CIOs in talking to their CEOs and budgeting committees: Based on this investment rate, like funding an R&D organization, I can do this much (X) for sure. If we're really lucky in discovering and developing new functionality, I can envision this dream level (Y) being achieved. And we are most likely to reach some intermediate level of functionality (Z). If X is sufficient for funding our loaded flow rate, let's get started.

Anyone with experience knows that any other statement of certainty is self-deception or worse. However, many people are so steeped in a false claims of predictability as a standard of professionalism that it's difficult to change those organizations.

In my Agile consulting, my prime objective is to create a safe environment for all to say, "I don't know." Then we can focus on delivery good stuff fast. As a matter of integrity, I hope all of us Agile, Scrum, XP, Kanban, Lean, etc. consultants do the same.

Jay
www.jconne.com

>
> On Wed, Jun 30, 2010 at 8:02 PM, Mark Levison <mark@...> wrote:
> >
> >
> > I've not met Adam so can claim to be neither a mentor or peer. However my experience chimes with his. Estimation is a waste. Estimation of tasks in hours is utter waste, people spend hours debating minutia, when they would better off just starting. Even estimation of stories in points is a waste, however to make your projects progress predictable and transparent this requires that stories be roughly the same size +/- one Delta. For most teams (mature or not) this turns out to be difficult, so they stick to story points.
>
>
> True, but I can imagine a highly functioning organization able to have
> the following conversation:
>
> Boss: "We have this really big thing we'd like you to do. What do you
> think it'll take?"
>
> Team: "We've done some other big things that aren't entirely different
> from that thing, and they took an average of about six months. So,
> we're thinking it'll take between four and eight months to get it all
> into production."
>
> Boss: "Great! I know that it costs about \$50K to keep you guys running
> for a month. That means that this is going to cost me about \$200-400K.
> Based on what we know of the market that should be well worth it. When
> will you have something to show us?"
>
> Team: "In about a week, but before we start let's sit down and write
> some user stories so that we can prioritize them and get a better feel
> for what the first pieces of functionality will be."
>
Your message has been successfully submitted and would be delivered to recipients shortly.