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

Re: Poll: Hours or Story Points?

Expand Messages
  • woynam
    Numerous people, including myself, will point out that measuring the goodness of planning is a waste of time. If you use velocity as a guide for planning,
    Message 1 of 55 , Apr 1, 2011
    • 0 Attachment
      Numerous people, including myself, will point out that measuring the "goodness" of planning is a waste of time. If you use velocity as a guide for planning, then it doesn't matter if your estimates are "good" or "bad".

      If you plan more than you can accomplish because your estimates are "low", then your velocity will reflect that, as the number of completed stories will be less then originally planned. You will then use that number in the next Sprint, assuming that your estimates for the next set of stories are just as "bad".

      Personally, I'd much rather see a team work on things that can actually shorten development, or make the code better, e.g. better testing, refactoring skills, continuous integration, etc.

      Mark

      --- In scrumdevelopment@yahoogroups.com, Rafael Nascimento <rafaelnascimento.rj@...> wrote:
      >
      > Brilliant people! Until now, very usefull and reflective comments! :)
      >
      > My teams in Brazil use both. We burn features, exactly as mentioned by Ron,
      > and ideal hours.
      >
      > Why?
      > The feature burning gives us the visibility of what´s done until a given
      > moment. It´s the reality, although we are burning lots of hours. The ideal
      > hours burning gives us a visibility of good or bad planning of tasks, and
      > it´s an entry for an analysis into a retrospective.
      >
      > Cheers!
      >
      >
      >
      >
      >
      > 2011/4/1 Charles Bradley - Scrum Coach CSM PSM I <
      > chuck-lists2@...>
      >
      > >
      > >
      > > > 1. How do you generate your sprint burndown charts? Considering hours or
      > > > story points?
      > >
      > > I just count the ideal hours of tasks that are not in the "done" column on
      > > the Scrum Board.
      > >
      > > > 2. Why?
      > >
      > > I recommend estimating Sprint tasks in ideal hours for the following
      > > reasons:
      > >
      > > - because I believe that to be the most accurate and transparent method
      > > of Scrum tasking (~5-6 ideal hours per day of Scrum tasks).
      > > - because it's a rule in the Scrum Guide.
      > > - because it's easier for humans to inspect and adapt their task
      > > estimating if it's in hours. So, eventually, the ideal hours converge
      > > towards the real/actual hours if the team continues to improve that skill.
      > > - because most humans are experienced in estimating in hours prior to
      > > beginning Scrum.
      > > - because it's easier to compare ideal hours remaining in the sprint to
      > > ideal hours of capacity left in the sprint.
      > >
      > > While the other methods mentioned so far are good, I do not believe that
      > > they are the best, because each lacks some amount of transparency. Not a
      > > lot lacking, just some small amount. OTOH, there is slightly more overhead
      > > in counting ideal task hours vs. counting stories or tasks. Instead of it
      > > taking 5 seconds (counting stories) or 20 seconds (counting tasks), it takes
      > > approximately 60-90 seconds to count ideal task hours. (Obviously, I think
      > > the extra minute a day is well worth the accuracy and transparency that that
      > > particular method provides).
      > >
      > > -------
      > > Charles Bradley, CSM, PSM I
      > > Experienced Scrum Coach
      > > My blog: http://scrumcrazy.wordpress.com/
      > >
      > >
      > > ------------------------------
      > > *From:* Ron Jeffries <ronjeffries@...>
      > > *To:* scrumdevelopment@yahoogroups.com
      > > *Sent:* Fri, April 1, 2011 2:19:03 AM
      > > *Subject:* Re: [scrumdevelopment] Poll: Hours or Story Points?
      > >
      > > Hello, Rafael. On Thursday, March 31, 2011, at 11:25:19 PM, you
      > > wrote:
      > >
      > > > 1. How do you generate your sprint burndown charts? Considering hours or
      > > > story points?
      > >
      > > Neither. Completed features (stories).
      > >
      > > > 2. Why?
      > >
      > > Completed features are what the project is about, and what the
      > > Product Owner wants.
      > >
      > > Ron Jeffries
      > > www.XProgramming.com
      > > In times of stress, I like to turn to the wisdom of my Portuguese waitress,
      > > who said: "Olá, meu nome é Marisol e eu serei sua garçonete."
      > > -- after Mark Vaughn, Autoweek.
      > >
      > >
      > >
      > > ------------------------------------
      > >
      > >
      > > To Post a message, send it to: scrumdevelopment@...
      > > To Unsubscribe, send a blank message to:
      > > scrumdevelopment-unsubscribe@...! Groups Links
      > >
      > >
      > >
      > >
      > >
      >
    • Steve
      Great post Matheus - couldn t agree more! Just one thing to add, if you do have non-located teams, capture the wall in some electronic form, send it to other
      Message 55 of 55 , May 17 9:00 AM
      • 0 Attachment
        Great post Matheus - couldn't agree more!

        Just one thing to add, if you do have 'non-located' teams, capture the wall in some electronic form, send it to other teams and get them to 'copy' it onto their wall. Someone may moan about the extra work to start with but everybody should soon see the advantages.

        --- In scrumdevelopment@yahoogroups.com, Matheus Gorino <lists@...> wrote:
        >
        > I've worked with Greenhopper for a while and I see 2 problems using it.
        >
        > 1. Every time they wanted to see it, they had to alt+tab to their browser,
        > then either ctrl+tab to the previously opened chart board tab, or click on
        > the chart board link, wait some seconds while it is generated, and see it.
        > As it takes some boring steps, they didn't see it much, and I, the SM, have
        > found myself for several times needing to check if they were looking at the
        > graph and knew where they were.
        > After introducing a physical chart, they didn't need to alt+tab anymore,
        > they just needed to raise their head and look at the wall, and they started
        > doing that several times a day. So it's not only having them to hand-draw
        > the chart (which I believe made them more "owners" of this artifact), but it
        > also increases visibility, what's is most important in my point of view.
        > For sure, this will not work if you don't have a co-located team, but if you
        > have a distributed team, the electronic vs. physical chart would be one of
        > the smaller problems I'd be concerned about, as you would be losing a lot of
        > other advantages of working co-located :)
        > Also, I don't think that your Client should be looking at the Sprint
        > burdown, as it is a Team's only artifact and it may be miss-interpreted by
        > people outside the team, putting unwanted/unnecessary pressure on them.
        >
        > 2. Worse than the electronic Chart board is the electronic Kanban board.
        > When using the Greenhopper Task board I found the team several times without
        > the vision of the whole and not doing one-piece-flow. As sometimes we have a
        > lot of Stories and Tasks, you need to use the browser's scrollbars to see
        > which Stories are opened, how many Tasks are in progress, and can not easily
        > balance between the To-do and Done column.
        > Switching to a physical Kanban board made everything more clear. Sometimes,
        > in the middle of the Sprint, looking at the To-Do column and seeing a lot of
        > items, and then looking at the Done and seeing few items, says much more
        > than the Burndown.
        > I no longer need to warn the team about the WIP and one-piece-flow, they now
        > perceive it much more easily. Now, when a developer gets up and go to the
        > board to pick a new task, everybody sees it and they are now asking each
        > other to help them close their current open tasks, instead of picking up a
        > new task on the wall.
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.