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.
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.
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...
That sounds like a problem. Not having a stable team composition will hurt *any* project, regardless if it's agile, waterfall or whatever. There is tacit...
It seems to me that often problems of 'agile development' are not problems of agile development at all, but problems external to that. This is a good example....
Roy Morien
roymorien@...
Sep 27, 2007 3:11 am
Welcome to Scrum! You will find valuable insights like this, and Scrum brings these issues to the front. Nicholas ... Nicholas Cancelliere Austin, TX Got sugu...
We did not have the "team switching problem" before Agile. . . ... From: Nicholas Cancelliere To: scrumdevelopment@yahoogroups.com Sent: Wednesday, September...
... Then I suggest that you stop the frequent switching, now. It's certainly an impediment. ... As long as you're changing the team membership, you'll never...
I am not saying no one was aware of this problem before Agile. It just brings light to these issues quickly. The person who posted said their velocity hasn't...
I'm as low on the power structure as one can get, so I'm won't be suggesting we stop switching teams, unless someone asks me - and I doubt that will happen! ...
... I should hope that no matter how low on the power structure you are, you would still be able to make suggestions! If you truely feel you can't safely make...
Quinton, Power isn't what changes things, though it can create the appearance. Influence is what really works. I would guess that you don't know how to ...
... This is a sore point with me. Maybe if the people writing new code were forced to do their own maintenance, mabe they would take the time to learn how to...
Malcolm Anderson
malcolm.b.anderson@...
Sep 27, 2007 8:45 pm
Amen Malcolm! Eat your own dog food. You should build what can be sustained over time. Knowing what you build could come back to haunt you should be some...
This is a great paragraph, I wish more teams found this insight. Nicholas ... -- Nicholas Cancelliere, CSM/CSP Business Analyst, InCircuit Development ...
Is 'old code maintenance' really such an awful job? There are some very highly paid 'old code maintenance' jobs out there for COBOL programmers, CICS...
Roy Morien
roymorien@...
Sep 28, 2007 1:48 am
... I'm with you on this one. Maintenance is actually more challenging than doing new stuff -- you have people actually and immediately depending on your work...
Before Agile, we did not switch teams, and we did not know our velocity. With Agile we switch teams, and we do not know our velocity. Other Executives in the...
It can help to utilize terms your executives understand to explain the gap between objective and accomplishment. Teams gel following the old standby of...
Hi there. We are 2 weeks away from our first anniversary of practicing Scrum across my company. For the most part, it has been an extremely Productive and...
Hi, velocity is measured by counting the number of story points done in the last iteration. I am not sure if it is suitable as a productivity metric. For me it...
... It is an exceptionally poor performance metric, unless your intent is only to see how your productivity stabilizes over time. Velocity has been used to...
I am using story points also to quantify how much work our team can get done during an average iteration. This figure is then used in release planning, and...
Jacob ... members [...] to the team, we can increase this figure Are you sure about that? That has not been my experience. I guess it depends how big the team...
Hi Tobias, Thanks for your reply. 'Adding members to increase team output' is not a philosophy. It's an experience of my own. There is, as you say, an initial...
Yes Jacob, Tobias is right. While you may see 'more' with larger teams, you also want to check the way the team and the SM are interacting. Repeatedly, teams...
It's worth pointing out ideal team size depends on the kind of work being done. 20 people picking cabbage manually will probably get more done than 7 +- 2. If...
<<*Once you get above 6-7 people it is unlikely to pick up again. *Interesting. Is this a fact which many scrum practicioners share? Of course, going higher...
... Qualitative assessments: run a long retrospective for each team covering the entire year, perhaps with an outside facilitator. This could take a day for...
I have an excellent 'metric' (well, metrics, if you want to be pedantic about it) to measure what you are wanting to measure. 1: The level of satisfaction of...
Offline 
Send Email