41785Re: [scrumdevelopment] Sprint planning using team capacity and detailed tasks vs.story-level estimates
- Oct 8, 2009Hi Mike:
I'm actually somewhere in the middle with this one. I think that for
most teams it is a progression which starts with getting good at
estimating in story points, getting stuff done, and having a
consistent burndown. Phase two is to get really good at breaking
stories down so that every story is small but has business value.
Finally, you arrive at what Ron is suggesting. They are all about the
same size and you know you can get them done in a day or two. When
they're any bigger than that you just break them down. No need to
So I guess I agree with Ron, I just think it takes a while to get
there and estimating is a remedial practice in the meantime.
As for estimating tasks in hours, we know that we are statistically
off by +/-40%. We have the studies to prove it. That's just a tad bit
better than random guessing. Seems like we'd be better of using that
time for something more valuable.
What I actually like is this:
1) Name your tasks so that you have a clear understanding of what
needs to be done. Don't track tasks individually or estimate them.
2) Once you agree on what the task are estimate in story points.
3) Keep the range of story points small. I use 1, 2, and 3. Where 1 is
small and 2 is big but both are much smaller than an iteration
(probably a day or two like Ron says.) 3 is big, but I don't know how
to break it down smaller. Every time I see that three it is a reminder
to try. Still, I can do a three inside a week. Any bigger than that
and I'm risking my Sprint. Any bigger than that and it must be broken
If you can get a team to the point where it is doing it this way and
is delivering value every sprint then you are probably close to being
able to do it Ron's way.
Another approach might be to measure cycle times and determine the
average size of a story that way. Sort of a Kanban hybrid. I like this
idea, but I've yet to try it.
Joshua Kerievsky says that his team does a kind of "Ultra Lean" where
they just do stories one at a time. Stories are all about the same
size, but there is no timebox. You just get a story and do it until
it's done. There is no Sprint review. Showing the implemented story to
the customer is part of the definition of done. I really, really like
the idea, but I'm not sure I've met more than a couple teams who I
think could pull that off. It might be a worthy place to try to get
once you've mastered what Ron is suggesting.
Anyway, my point is that it's all about continuous improvement. There
isn't a right way. Just levels of goodness that teams can strive for.
On Thu, Oct 8, 2009 at 6:04 AM, <mike.dwyer1@...> wrote:
> The most interesting muscle memory we break with agile and scrum is the importance a good time estimation and replacing it with a focus on steady delivery of value. Roy is completely on target.
> Mike Dwyer
> Sent via BlackBerry by AT&T
> From: Ron Jeffries <ronjeffries@...>
> Date: Thu, 8 Oct 2009 07:53:00 -0400
> To: <email@example.com>
> Subject: Re: [scrumdevelopment] Sprint planning using team capacity and detailed tasks vs.story-level estimates
> Hello, Michael. On Thursday, October 8, 2009, at 7:13:00 AM, you
> > Some people work better when there is a sense of urgency when
> > work are time boxed. This may have nothing to do with " PROPHECY"
> > or wanting to be correct in estimating.
> I suspect that at the beginning one needs no urgency, and no
> estimation or estimation tracking. One needs to start writing
> software and getting it done.
> Ron Jeffries
> Will Turner: This is either madness or brilliance.
> Captain Jack Sparrow: It's remarkable how often those two traits coincide.
- << Previous post in topic Next post in topic >>