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

Velocity

Expand Messages
  • Quinton
    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
    Message 1 of 40 , Sep 26, 2007
      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.

    • Michael Vizdos
      I ll try to address your questions in-line below... Useful links, comics, and blog postings about this topic are located at the end of this response (for
      Message 40 of 40 , Jun 29, 2009
        I'll try to address your questions in-line below... Useful links,
        comics, and blog postings about this topic are located at the end of
        this response (for those that want more details).

        Thank you,

        - Mike Vizdos

        Contact Information

        Web: www.implementingscrum.com
        www.michaelvizdos.com
        AOL IM: MikeV Work
        Twitter: www.twitter.com/mvizdos
        Skype: mvizdos

        PS: Come to one of my workshops. Visit michaelvizdos.com/enroll.

        PPS: Visit implementingscrum.com/subscribe. Receive 2 FREE videos.

        On Mon, Jun 29, 2009 at 4:40 AM, Vikas Atri<vikasait25@...> wrote:
        >
        >
        > I  have concerns over estimation methodology used in scrum.
        >
        > Had been spawning across couple of sites, but wasnt satisfied.
        > Just want to know from others experience here that :
        > Does story points reflect size (vis-a-vis against traditional life cycle
        > estimations like function points)
        > I read it in couple of sites(scrum alliance/mountaingoatsoftware etc) that
        > poker technique is used in estimating (efforts) for user stories in sprint.
        > The size estimates (story points) are in fibonacci series order.
        > 1,2,3,5,8,13
        >
        > 1> What all factors are considered to arrive at story points?


        I think Roy has done a great job at answering that one (nice)! Let us
        know if you have other questions. One thing I'd add is that in
        reality story points mean nothing outside of the team and can / should
        differ from team to team. One of the goals for using Story Points is
        to come to a more predictable velocity for the team.


        > 2>What do we really mean by these mere numbers like 1, 2 ,3...etc


        You can use any number sequence you'd like. I'd recommend what you
        have started in your next question...


        > 3> What is the logic of selecting fibonacci series while estimating
        > (efforts) for user story.


        That series is useful to me because they are easy numbers for a team
        to wrap their heads around, and people can make easier estimates over
        a 3 point versus 8 point story (see Mike Cohn's Planning Poker for
        more information). Also, once the series gets to about 20 (not 21), I
        usually just use 20, 40, and a question mark. Remember these are
        *estimates* based on the teams experience and having some number like
        21 or 42 starts to imply an accuracy that is, in reality, false.



        > 4> At what step are the user stories broken down into tasks ? Is it like
        > User story -> story points -> Efforts


        I usually break down User Stories into Tasks with the team during
        Sprint Planning. This is where I make the jump from points to "hours
        of remaining effort" that will help the team track to the burndown
        chart and get more focused on what "Done" starts really looking like.



        > 5>If above be the case then how can the efforts be justified against story
        > point numbers like 1,2,3,5...
        > i.e what is the basis of arriving at efforts from story points
        > (1,2,3,5,8,13)


        This one is hard to swallow. There is no correlation between story
        points and effort of hours remaining for a Sprint. I am sure that
        statement will spark some interesting comments so I'll leave it at
        that.


        >
        > Regards,
        > Vikas
        >
        >

        Hope this helps.

        I have some comic strips on the topic (and blog entries specific to
        this topic) at:

        http://www.implementingscrum.com/2008/06/04/planning-poker-a-one-night-stand-lets-hope-not/

        http://www.implementingscrum.com/2007/06/11/ya-got-to-know-when-to-fold-em/

        - mike vizdos
      Your message has been successfully submitted and would be delivered to recipients shortly.