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

Re: Spike user stories

Expand Messages
  • Giora Morein
    ... What I have found that works best for the teams I work with, is sizing points at the story level withing the product backlog, and then estimating hours for
    Message 1 of 33 , Aug 1, 2006
    • 0 Attachment
      --- In scrumdevelopment@yahoogroups.com, "aefager" <aefager@...> wrote:

      > I just want to get a clarification here.
      > 1. You are a proponent of accurate estimation.
      > 2. You are a proponent of Scrum.
      > 3. You are a proponent of story points over hours.
      >
      > Does this mean that in a burndown chart, you would use story points,
      > in place of hours? Do you still have burndowns, and are now doing
      > them on story points, or did I misunderstand?
      >


      What I have found that works best for the teams I work with, is sizing
      points at the story level withing the product backlog, and then
      estimating hours for each task identified for each planned story
      during sprint planning. This is also what Mike Cohn speaks about in
      his "Agile Estimation and Planning" session. This way you are able to
      have a Sprint Burndown in hours, reflecting work remaining for the
      sprint, and Release Burndown or Product Burndown in Story Points.

      Giora Morein
      gmorein@...
    • Ron Jeffries
      Hello Marco, thanks for sharing your thoughts. On Monday, August 21, ... Yes. In my opinion, this is a sure sign that the story sizes are too widely varying,
      Message 33 of 33 , Aug 21, 2006
      • 0 Attachment
        Hello Marco, thanks for sharing your thoughts. On Monday, August 21,
        2006, at 9:26:38 AM, you wrote:

        >> Nonetheless, I like a story / feature burndown at the project level,

        > I agree with you if you managed to have fairly similar stories size/effort
        > wise but when you have stories of different size/effort a story/feature
        > burndown is misleading because it doesn't show you how much effort you
        > still need to put into the project if you want to deliver them all.

        Yes. In my opinion, this is a sure sign that the story sizes are
        too widely varying, and it's the thing to fix. Failing that, story
        points or some other pure estimate works well.

        > I spend at least one day every week discussing this same issue with my
        > current customer's managers. They like the total effort based
        > burnup/burndown but at the same time want a chart based on number of
        > stories and give to the latter one more weight. But they communicate
        > different messages! Example:

        > - 10 stories for the release of product X
        > - 5 of them have an estimate of 1 WUYU (whatever unit you use...)
        > - 5 of them have an estimate of 3 WUYU
        > - for various reason you cannot/don't want to split the bigger one down
        > - 1 of the 3 WUYU stories yet to be done

        > an effort based chart will show you that you still have 3 WUYU to do and
        > you can use your velocity to commit to a date while a story/feature chart
        > will show you only that you still have 1 story to do without an indication
        > of what that means.

        Yes, but ... when you have 4 stories this actually has an effect.
        When you have 40 or 100, it turns out that the count tracks the work
        units just fine. Law of large numbers hits quite early. Try it
        sometime.

        > You can have situations in which people are worried because you still have
        > 4 stories to do not considering they are small, 1 WUYU stories and, at the
        > same time, people not worried at all if you still have 2 story to do even
        > if it is a 3 WUYU one.

        Yes. I prefer to work with approximately two stories per programmer
        per week. In that case ... this becomes a non issue.

        Thus my "advice" is to use story count ... and do what has to be
        done to make it work, which usually means many stories of
        approximately the same size.

        Regards,

        Ron Jeffries
        www.XProgramming.com
        Find the simple path to what works and follow it,
        always looking for a simpler path. -- Patrick D. Smith
      Your message has been successfully submitted and would be delivered to recipients shortly.