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

Re: [scrumdevelopment] Re: Tasks hours vs story points

Expand Messages
  • shankar moorthy
    Isn t there a way to compare the velocity of the project against a benchmark? Shankar Kris 1 847 363 1675 ________________________________ From: davenicolette
    Message 1 of 71 , Mar 27, 2009
    • 0 Attachment
      Isn't there a way to compare the velocity of the project against a benchmark?
       
      Shankar Kris
      1 847 363 1675



      From: davenicolette <dnicolet@...>
      To: scrumdevelopment@yahoogroups.com
      Sent: Friday, March 27, 2009 2:15:53 PM
      Subject: [scrumdevelopment] Re: Tasks hours vs story points

      In about 2 to 4 sprints, depending on circumstances. Key issues that affect velocity are (a) whether the team is working together for the first time, (b) whether the team has domain knowledge, and (c) whether the team is familiar with the technologies they're using. Once these things settle in, the team will settle into its normal velocity, too. It takes a surprisingly short time.

      There's some explanatory information and a sample spreadsheet here: http://davenicolett e.wikispaces. com/Agile+ Metrics

      Bear something in mind, though: We aren't talking about "estimates improving" or "team getting faster." Velocity is an empirical observation of the team's capacity for work. It's an observation of reality that you can use to project a completion date for a given scope; it isn't a "target" or "goal" for the team to "aim for." That's a slightly different perspective than traditional "estimates vs. actuals" metrics. This is one of the reasons using time as a unit of measure doesn't quite make sense in this context.

      Cheers,
      Dave

      --- 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:scrumdevelo pment@ 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.