- The members of our teams are changing so frequently - and we gain and lose developers / QA folks in the companysay 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 -----From: Nicholas CancelliereSent: Wednesday, September 26, 2007 7:26 PMSubject: 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.NicholasOn 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.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.NicholasOn 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 astory that takes 60 hours, and that there are only 40 hours left in youriteration (from a planning point), and he goes around the room adding uppeople/weeks, and says. Oh no. I see at least 100 hours left.--Nicholas Cancelliere, CSM/CSPBusiness Analyst, InCircuit Development
P Before printing this, think about the environment.---Nicholas CancelliereAustin, TXP Before printing this, think about the environment.--Nicholas Cancelliere, CSM/CSPBusiness Analyst, InCircuit Development
P Before printing this, think about the environment.---Nicholas CancelliereAustin, TXGot sugu on the brain?P Before printing this, think about the environment.
- 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).
- Mike Vizdos
AOL IM: MikeV Work
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> 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
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
Hope this helps.
I have some comic strips on the topic (and blog entries specific to
this topic) at:
- mike vizdos