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

24070Velocity

Expand Messages
  • Quinton
    Sep 26, 2007
    • 0 Attachment
      The members of our teams are changing so frequently - and we gain and lose developers / QA folks in the company
       
      say every 6 - 8 sprints - so figuring out velocity so far has not "matured"
       
      any guess how many sprints to get an accurate velocity?
       
       
      ----- Original Message -----
      Sent: Wednesday, September 26, 2007 7:26 PM
      Subject: Re: [scrumdevelopment] Why points are lame...


      He can assume that if all things were the same, but rarely are they.

      The point is that as time goes on people are more experienced, the system changes (sometimes making things easier, sometimes harder), etc.  You might try to educate him on what team velocity is and how he can use that to gauge how much work can be done.

      Nicholas


      On Sep 25, 2007, at 8:46 AM, Jeff Martin wrote:

      This is the issue I’m having the most trouble communicating to my CFO.  He thinks that if Story A was 5 points and took 20 hours then if Story B is also 5 points, it will take 20 hours.  I’ve tried to explain that, over time, it may equal out that way, but you can depend on it being a direct correlation.   I’m considering just switching to “perfect man (or team) days” because we end up just going back and forth on what a point “is” and not moving forward on the project.
      From: scrumdevelopment@ yahoogroups. com [mailto:scrumdevelop ment@yahoogroups .com] On Behalf Of Nicholas Cancelliere
      Sent: Monday, September 24, 2007 8:11 AM
      To: scrumdevelopment@ yahoogroups. com
      Subject: Re: [scrumdevelopment] Why points are lame...
      I don't agree with the statement about "if you're using hours then you're already using story points."  This confusion between story points = duration is how this thread was even started.  You cannot equate Story Points to a duration, if you are then you're really just calling an "hour" by some other name, which misses the concept completely.
      Story Points are an estimate of size and complexity -- they don't communicate duration.  
      When you use hours for estimating you're estimating the duration, how long it'll take to get done.  That could change based on the experience  of the team.
      Nicholas
      On Sep 24, 2007, at 6:45 AM, mpkirby wrote:


      But if your estimation accuracy is variable (like it is for most of us), 
      then you are already using story points.  You just call them hours. 
      And I think that's the point.  When you tell your CTO that you have a 
      story that takes 60 hours, and that there are only 40 hours left in your 
      iteration (from a planning point), and he goes around the room adding up 
      people/weeks, and says.  Oh no.  I see at least 100 hours left.
      --
      Nicholas Cancelliere, CSM/CSP
      Business Analyst, InCircuit Development
      512-347-7400 x123 -- http://www.incircui t.com
      For support on InCircuit products contact support@incircuit. com or call 800-963-1950 ext 2.

      P     Before printing this, think about the environment.



      ---
      Nicholas Cancelliere
      Austin, TX
      P     Before printing this, think about the environment.

      --
      Nicholas Cancelliere, CSM/CSP
      Business Analyst, InCircuit Development
      512-347-7400 x123 -- http://www.incircui t.com

      For support on InCircuit products contact support@incircuit. com or call 800-963-1950 ext 2.

      P     Before printing this, think about the environment.



      ---
      Nicholas Cancelliere
      Austin, TX


      P     Before printing this, think about the environment.

    • Show all 40 messages in this topic