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

Re: [scrumdevelopment] Re: Estimating - with story points, hours or both?

Expand Messages
  • Angela Druckman
    It is only useful as a visual reference to make it crystal-clear when the lines are diverging, which is what I would use a traditional burndown for as well--
    Message 1 of 21 , Aug 31, 2008
      It is only useful as a visual reference to make it crystal-clear when the lines are diverging, which is what I would use a "traditional" burndown for as well--

          --Angela


      ----- Original Message ----
      From: "James S. Fosdick, PMP, CSP" <jsfosdickcsp@...>
      To: scrumdevelopment@yahoogroups.com
      Sent: Tuesday, August 26, 2008 4:46:26 PM
      Subject: [scrumdevelopment] Re: Estimating - with story points, hours or both?

      Just out of curiosity, what value to do you feel is derived from
      charting an "ideal" burndown? I used to do that, but someone persuaded
      me that it wasn't adding value and when I've tried just charting the
      task (or story) burndown I see no effect from removing the ideal line.

      --- In scrumdevelopment@ yahoogroups. com, Angela Druckman
      <angela.druckman@ ...> wrote:

      >
      > Hi Matt -
      >
      > I can't speak for Luciano but, since I started the thread, I can
      tell you how my teams do this.
      >
      > We chart "ideal vs actual story point" burndown. For example, let's
      say there are 15 working days in the sprint and the team commits to 30
      story points (for simple math). So an "ideal" or even burndown is 2
      story points each day, for 15 days. That is our baseline.
      >
      > Against that we chart how the story points actually got completed.
      My experience is that story point burndowns look a bit like stair
      steps, not a smooth line, but gives you even more useful information
      that traditional burndowns because, at the end of the day, what
      matters are the number of stories complete--
      >
      > --Angela
      >
      >
      >
      >
      > ----- Original Message ----
      > From: Matt McClure <mlm@...>
      > To: scrumdevelopment@ yahoogroups. com
      > Sent: Sunday, August 24, 2008 5:27:14 AM
      > Subject: Re: [scrumdevelopment] Re: Estimating - with story points,
      hours or both?
      >
      >
      > Luciano,
      >
      > On Wed, Aug 20, 2008 at 8:38 AM, Luciano Felix <lucianofelix@
      gmail.com> wrote:
      > > For the tasks we don´t estimate at all, we just identified as many
      tasks as
      > > possible and commit with a number of stories to be done by the end
      of the
      > > sprint, and don´t worry if a task gonna take 4 or 6 hours. The
      important is
      > > to try to deliver what was committed on the planning.
      >
      > This sounds like a compelling way to simplify iteration planning
      > meetings. But how do you chart your iteration burndown without task
      > estimates?
      >
      > Matt
      >


    • hmeftah
      Hi Angela, Use story points to estimate your backlog, apply your team velocity, translate in days or hours if you want to. Don t worry about tasks duration,
      Message 2 of 21 , Sep 3, 2008
        Hi Angela,

        Use story points to estimate your backlog, apply your team velocity,
        translate in days or hours if you want to.

        Don't worry about tasks duration, some of them may be longer than
        expected, the aim is all should be done at the end of the Sprint.

        The best thing in Scrum is stories are time boxed, coupled with an
        iterative development to deal with the uncertainty of the requirements.

        Have a look to the good book, Agile Estimating and Planning.

        Don't forget the first Scrum quote: " Inspect and Adapt".
        Each project and team are unique, some concept may work with one
        team/project but fail with an other.
        H. Meftah
      • Angela Druckman
        Yes, thanks - I have a technique that works well for my teams- we estimate only with story points and don t use hours at all.  My teams have consistently
        Message 3 of 21 , Sep 3, 2008
          Yes, thanks -
           
          I have a technique that works well for my teams- we estimate only with story points and don't use hours at all.  My teams have consistently estimated worse with hours than with a more relative scale.  I was more curious what others are doing and what they have found effective.
           
          Thanks--
           
               --Angela

           

          ----- Original Message ----
          From: hmeftah <hmeftah@...>
          To: scrumdevelopment@yahoogroups.com
          Sent: Wednesday, September 3, 2008 2:52:43 AM
          Subject: [scrumdevelopment] Re: Estimating - with story points, hours or both?

          Hi Angela,

          Use story points to estimate your backlog, apply your team velocity,
          translate in days or hours if you want to.

          Don't worry about tasks duration, some of them may be longer than
          expected, the aim is all should be done at the end of the Sprint.

          The best thing in Scrum is stories are time boxed, coupled with an
          iterative development to deal with the uncertainty of the requirements.

          Have a look to the good book, Agile Estimating and Planning.

          Don't forget the first Scrum quote: " Inspect and Adapt".
          Each project and team are unique, some concept may work with one
          team/project but fail with an other.
          H. Meftah


        • James S. Fosdick, PMP, CSP
          Late to the party, but has anyone mentioned T-Shirt sizes? That s almost always my preferred method as it s the most abstract and the hardest to game . Of
          Message 4 of 21 , Sep 3, 2008
            Late to the party, but has anyone mentioned T-Shirt sizes? That's
            almost always my preferred method as it's the most abstract and the
            hardest to "game". Of course it's predicated on doing commitment based
            planning rather than velocity based planning which some teams don't
            like. In my view getting the team wrapped up in velocity numbers
            (which we really only care about for long range planning of releases
            and such) is high risk and low value. But that's just me. :)

            --- In scrumdevelopment@yahoogroups.com, Angela Druckman
            <angela.druckman@...> wrote:
            >
            > Yes, thanks -
            >
            > I have a technique that works well for my teams- we estimate only
            with story points and don't use hours at all.  My teams have
            consistently estimated worse with hours than with a more relative
            scale.  I was more curious what others are doing and what they have
            found effective.
            >
            > Thanks--
            >
            >      --Angela
            >
            >  
            >
            >
            > ----- Original Message ----
            > From: hmeftah <hmeftah@...>
            > To: scrumdevelopment@yahoogroups.com
            > Sent: Wednesday, September 3, 2008 2:52:43 AM
            > Subject: [scrumdevelopment] Re: Estimating - with story points,
            hours or both?
            >
            >
            > Hi Angela,
            >
            > Use story points to estimate your backlog, apply your team velocity,
            > translate in days or hours if you want to.
            >
            > Don't worry about tasks duration, some of them may be longer than
            > expected, the aim is all should be done at the end of the Sprint.
            >
            > The best thing in Scrum is stories are time boxed, coupled with an
            > iterative development to deal with the uncertainty of the requirements.
            >
            > Have a look to the good book, Agile Estimating and Planning.
            >
            > Don't forget the first Scrum quote: " Inspect and Adapt".
            > Each project and team are unique, some concept may work with one
            > team/project but fail with an other.
            > H. Meftah
            >
          Your message has been successfully submitted and would be delivered to recipients shortly.