Loading ...
Sorry, an error occurred while loading the content.

41785Re: [scrumdevelopment] Sprint planning using team capacity and detailed tasks vs.story-level estimates

Expand Messages
  • Adam Sroka
    Oct 8, 2009
      Hi 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
      estimate.

      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
      down.

      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:
      >
      >
      >
      > Ron
      > 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: <scrumdevelopment@yahoogroups.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
      > wrote:
      >
      > > 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
      > www.XProgramming.com
      > www.xprogramming.com/blog
      > Will Turner: This is either madness or brilliance.
      > Captain Jack Sparrow: It's remarkable how often those two traits coincide.
      >
      >
    • Show all 19 messages in this topic