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

Re: Tasks hours vs story points

Expand Messages
  • woynam
    Sure. The velocity can be calculated at the end of every iteration. Generally speaking it typically takes a few iterations to stabilize, but you ll have a
    Message 1 of 71 , Mar 27, 2009
    • 0 Attachment
      Sure. The velocity can be calculated at the end of every iteration. Generally speaking it typically takes a few iterations to stabilize, but you'll have a value at the end of the first iteration.

      Mark

      --- In scrumdevelopment@yahoogroups.com, shankar moorthy <l_shankar2003@...> wrote:
      >
      > So,you mean the velocity can be approximately determined after say,2 sprints??
      >
      > Shankar Kris
      > 1 847 363 1675
      >
      >
      >
      >
      > ________________________________
      > From: woynam <woyna@...>
      > To: scrumdevelopment@yahoogroups.com
      > Sent: Wednesday, March 25, 2009 3:23:36 PM
      > Subject: [scrumdevelopment] Re: Tasks hours vs story points
      >
      >
      >
      > Only if you re-estimate the stories in the backlog, which is genrally a no-no. The value of velocity-based calculations is based on keeping the estimation process consistent across all stories and Sprints.
      >
      > So, if the team is getting better (faster) at delivering finished stories, the velocity should go up given that we're comparing apples to apples.
      >
      > That said, my experience has been that a team's velocity doesn't really change that much over the course of an extended project unless you're introducing some big-time training in the engineering practices.
      >
      > Mark
      >
      > --- In scrumdevelopment@ yahoogroups. com, "ejackson11" <ejackson@ .> wrote:
      > >
      > >
      > > The idea that your velocity can improve over the course of several
      > > sprints make sense. However, as the team's velocity increases, so does
      > > the amount of work completed per story point. In other words, what
      > > seemed difficult and took 10 story points to deliver several months ago,
      > > may now by easy and only take 3 story points to deliver.
      > >
      > > Therefore, your velocity would actually stay constant if measured as
      > > story points/time . . . what am i missing here??
      > >
      > > --- In scrumdevelopment@ yahoogroups. com
      > > <mailto:scrumdevelopment@ yahoogroups. com> , Tapio Kulmala
      > > <tapiokulmala@ > wrote:
      > > >
      > > > Hi Mike.
      > > >
      > > > IMHO, hours can't be used as as velocity metric.
      > > >
      > > > Story point show quite well how the team is getting better and better.
      > > The
      > > > velocity of consecutive sprints might be something like 30, 40, 37,
      > > 42,
      > > > 47.....50, 60. Basically your velocity has doubled. If the previous
      > > example
      > > > of numbers were days, you'd be tracking something else. If your team's
      > > > absolute maximum available working days during a spint were 40, how
      > > can they
      > > > achieve velocity of 60 days? Their maximum velocity should be 40.
      > > Everything
      > > > above 40 does not mean that the team is getting better. It only tells
      > > us
      > > > that their story/task estimates are getting worse or that they have
      > > worked a
      > > > lot overtime.
      > > >
      > > > Does this make any sense?
      > > >
      > > > Tapio
      > > >
      > > >
      > > >
      > >
      >
    • Ron Jeffries
      ... Yes. The best driver in the world won t get around the track in 1/2 the time of the average driver. Whatever level of performance a team has, they ll
      Message 71 of 71 , Apr 2, 2009
      • 0 Attachment
        Hello, Ryan. On Thursday, April 2, 2009, at 8:29:25 AM, you wrote:

        > I have seen first hand what happens when execs get ahold of team
        > velocity and get fixated on making that number higher, saying things
        > like, "We can make our release with all the features promised if we
        > can just get our velocity up to 70 points per iteration". While we
        > should all be challenged to do better each sprint, wanting/wishing/
        > hoping for a 50% improvement in velocity is unrealistic. Velocity is
        > what it is.

        Yes. The best driver in the world won't get around the track in 1/2
        the time of the average driver. Whatever level of performance a team
        has, they'll likely improve by percentages, not by multiples.

        Demanding such changes is almost certainly going to be harmful.

        > But my larger point is this: I bet 90% of the agile teams today spend
        > more time and energy on measuring and managing velocity than
        > measuring and managing the value of their work. I would say most
        > agile teams I see (and read about) are overly focused on building the
        > thing right and under focused on building the right thing. You need
        > to do both, but current agile thinking focuses much more attention on
        > the former and far too little on the latter, which is a shame.

        Yes. Surely the relative value of stories is at least 10x, and so is
        the cost. So there are things to do that cost 1 and are worth 100,
        while others cost 100 and are worth 1. The difference due to choice
        is profound.

        Ron Jeffries
        www.XProgramming.com
        www.xprogramming.com/blog
        You are to act in the light of experience as guided by intelligence.
        -- Nero Wolfe
      Your message has been successfully submitted and would be delivered to recipients shortly.