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

Re: [scrumdevelopment] Estimate Stories or tasks?

Expand Messages
  • Ron Jeffries
    Hello, Adam. On Saturday, February 20, 2010, at 3:21:22 AM, you ... All that is necessary for this to be true -- and it is true, by the way -- is that stories
    Message 1 of 59 , Feb 20, 2010
      Hello, Adam. On Saturday, February 20, 2010, at 3:21:22 AM, you
      wrote:

      > I have only done this for about six teams so far, but the math is
      > solid. If the pattern holds for other teams (And the teams have to be
      > doing Scrum somewhat competently to count) it supports what I have
      > believed for some time - that story "sizes" aren't statistically
      > significant to velocity.

      All that is necessary for this to be true -- and it is true, by the
      way -- is that stories have a roughly equal mean size over time.

      Because people like it when they get about the same visible amount
      of work done every Sprint, teams will tend to keep stories about the
      same size.

      Because smaller stories are easier to complete and have fewer
      surprises, teams will tend to keep stories small (which is one kind
      of "about the same size").

      Therefore, it's just fine to count the stories.

      Now then, let's talk about why even counting the stories isn't all
      that important. This topic is advanced. Reader, your team may not be
      able to work this simply. You might not be ready for this. Do not
      try it at home unless your team is in the top 25 percent.

      Estimation is clearly "waste". It's not software. You may think of
      it as "necessary waste". Turns out it's not as necessary as you may
      have thought. Here's why:

      The Product Owner's job is to have the best possible product by the
      delivery date, by managing scope. To do this best, these fairly simple
      strategies suffice:

      1. Make stories as small as possible so as to get feedback quickly;
      2. Work in thin lines to fill in the breadth of the product;
      3. Define "Done" to include working all the way from top to bottom;
      4. Initially, pick stories to get a barely functional system;
      this doesn't take a big percentage of the time;
      5. Thereafter, pick stories that are shiny and that fill in the
      product nicely.

      None of the above requires counting stories, much less any kind of
      real estimation. All it requires is the ability to answer the
      question "can we do this story within a few days with a few people?"


      Estimating tasks is pernicious, leading only to harmful behaviors.
      Estimating stories is unnecessary waste beyond "a few days".

      Estimation and burn charts are training wheels. But maybe don't take
      off your training wheels just yet. Just look at yourself and see
      whether estimation is actually doing you any good.

      If estimation IS doing you some good, maybe you should think about
      it as a kind of waste, and try to get rid of it.

      Ron Jeffries
      www.XProgramming.com
      www.xprogramming.com/blog
      New and stirring things are belittled because if they are not belittled,
      the humiliating question arises, "Why then are you not taking part in
      them?" -- H. G. Wells
    • Jordi Salvat i Alabart
      http://www.pomodorotechnique.com/ 2010/4/8 john_hermann
      Message 59 of 59 , Apr 8, 2010
        http://www.pomodorotechnique.com/

        2010/4/8 john_hermann <john_hermann@...>
         

        Perhaps "iScrum" :-)

        --- In scrumdevelopment@yahoogroups.com, Heitor Roriz Filho <hroriz@...> wrote:
        >
        > Personal-Scrum?
        >
        > On Tue, Feb 23, 2010 at 2:59 AM, john_hermann <john_hermann@...>wrote:
        >
        > >
        > >
        > >
        > >
        > > To take that down one order of magnitude further:
        > >
        > > In my individual work, I like to break things into Scrum-like "sprints" of
        > > uninterrupted work about 1 hour long. 1-1.5 hours is apparently the average
        > > attention span of adults (which helps explain the length of univerity
        > > classes, work meetings, conference sessions, etc.).
        > >
        > > I like to call this "sprint" technique the "golden hour" (in reference to
        > > medical surgeons treating severe injuries):
        > > - Plan what to do.
        > > - Do it (there is no "try" :-)), checking in with myself every few minutes
        > > to see if I am adding value or getting distracted (the "daily standup").
        > > - Review it.
        > > - Retrospect how I could have handled the situation better.
        > >
        > > I believe a good chunk of work can be accomplished in a golden hour. It is
        > > likely too granular for Scrum Teams with proper sprints, but might just work
        > > at say a pair-programming level.
        > >
        > > -johnny
        > >
        > >
        > > --- In scrumdevelopment@yahoogroups.com<scrumdevelopment%40yahoogroups.com>,
        > > George Dinwiddie <lists@> wrote:
        > > >
        > > > Heitor,
        > > >
        > > > Heitor Roriz Filho wrote:
        > > > >
        > > > >
        > > > > Ron, my bad. I got so excited with this post that I mixed 1-day (which
        > > > > is IMO not feasible) with 1-week (which is OK, though the smallest
        > > > > sprint I worked with was 2 weeks).
        > > >
        > > > I've heard reports of 1-day sprints being successfully used. I'm very
        > > > wary about saying what is "not feasible." At one time, many people said
        > > > the 4 weeks mentioned by the canonical scrum rules was "not feasible."
        > > >
        > > > - George
        > > >
        > > > --
        > > > ----------------------------------------------------------
        > > > * George Dinwiddie * http://blog.gdinwiddie.com
        > > > Software Development http://www.idiacomputing.com
        > > > Consultant and Coach http://www.agilemaryland.org
        > > > ----------------------------------------------------------
        > > >
        > >
        > >
        > >
        >


      Your message has been successfully submitted and would be delivered to recipients shortly.