Re: [scrumdevelopment] Why points are lame...
- I do not disagree with you. This threadoriginally started out with the idea that"story points are lame," which I disagreedwith.Next some compared points to hour estjust not callin them that.Then even further people were saying youcould have, in the same sprint, twostories of the same size in story pointsbe estimated days apart.Then one wonders how the CTO isfrustrated and confused.See my earlier posts for my thoughtson the thread.Nicholas
--Nicholas CancelliereAustin, TXSent from my Apple iPhone
On Oct 1, 2007, at 2:24 AM, Roy Morien <roymorien@...> wrote:I am troubled by this discussion. Personally, I am just as cynical about estimating accuracy as anybody, and indeed there is always a learning experience to be had whenever we do anything. But I am uncomfortable with the notion that "it's just that the guesses proved to be wrong in hindsight. To say they were mis-estimated gives the impression that we want them to be more accurate" ... well, YES, I would like to think that our estimates can be somewhat more accurate, without, of course, always being seen as concrete quotes. Yes, our 'guesses', more usually termed estimates, maybe be proved wrong in hindsight, but that happens all the time .. hindsight being the time when we can have reasonable certainty, especially about the past.
I do agree that often a lot of detailed analysis can be put into estimating, and in the big picture that time and effort is wasted, or provides little real value.
But we cannot escape the reality that at an early stage of the system development project, clients WILL WANT a reasonably accurate estimate of Time and Cost for the project. This is a major input into the decision making process on a GO-NO GO decision for the project, and calculations on ROI and business value of the project.
The fact is that while we continue to try to box organisational system development into neat parcels called projects, we will have this requirement.
As a one-time practicing accountant, I have always wondered why this project emphasis even came into place in the first place. I wonder how the Financial Accountant could function if his work was always packaged into 'projects'. Maybe things like 'payment of at least 20 invoices plus banking of at least 25 cheques' ... something like that. This is of course an absurdity, and the organisations accounting function is seen as an ongoing activity, with, of course, certain necessary deadlines. These deadlines are known, and readily achieved, partly because of the experience of the accounting functionaries on many previous occasions. But even then, the financial accountant has the luxury of 'closing off' and then a period of time after that to get everything of relevance before the 'closing off' time up to date and processed.
So why can't the system development activity be seen as a continuing activity? Every 2 weeks some additional functionality is delivered, either as new features, or updated and enhanced features, with significant deadlines stated, which we might call, hmmm, Releases.
This might acknowledge the software development process as being quite unstructured and prone to being uncertain. This uncertainty may be caused by incompetent, lazy and irresponsible development personnel, but usually is not. It is usually caused by all sorts of other development and technical matters.
It's actually a bit like a lawyer preparing a case. It is not expected that the lawyer have the entire coda of Law fully understood and known. Time is usually taken to research the Law to see what is appropriate to the specific case ... and the Client is charged for that legal 'ignorance'. Apparently system developers are not allowed to have any technical or developmental 'ignorance' that might disrupt the continuous 'production line' nature of software development.
hmmm .. sorry ... just ranting a bit here.
Date: Sun, 30 Sep 2007 18:55:07 -0700
Subject: Re: [scrumdevelopment] Why points are lame...Exactly, and I'm agreeing with you. For planning they were both 5 point stories. They were not necessarily mis-estimated, it's just that the guesses proved to be wrong in hindsight. To say they were mis-estimated gives the impression that we want them to be more accurate, right?
I don't like to make this value judgement because putting it usually provides a force for evil; namely, the team will want to do enough work on stories to get the estimated correct *before* we decide their priority. Yes, after we choose them for the Sprint Backlog we would expect their *task* estimates to be a little closer, but not before -- this leads to premature analysis and design, IMHO.
Now, if you want to do this premature analysis and design, write a (spike) story for it -- just make sure it's accounted for in some Sprint Backlog so that the team gets credit for it.
Dan Rawsthorne, PhD, CST Senior Coach, Danube Technologies dan@..., 425-269-8628
Nicholas Cancelliere wrote:You're talking about the duration they took after the fact. I would just say in your case you grossly misestimated, and chalk it up as a learning experience.What I am talking about is in planning.NicholasOn Sep 28, 2007, at 7:57 PM, Dan Rawsthorne wrote:I don't think you could say that. However, you could easily say that one5-point story took 1 day and another 5-point story took 10 days - it'sall about what you find when you get there.Dan Rawsthorne, PhD, CSTSenior Coach, Danube Technologiesdan@..., 425-269-8628Nicholas Cancelliere wrote:I don't think you can -- not in the same iteration. That wouldn'tmake sense to me either and I would rightfully question that. Can youexplain to me how you have 2 different 5 point stories?NicholasOn Sep 27, 2007, at 8:20 PM, Roy Morien wrote:A situation that becomes very hard for the uninitiated to swallow ...how can you say that one feature is measured at 5 story points andcan be completed in a day, but another '5 pointer' will take 4 days?------------ --------- --------- --------- --------- --------- --------- ------Date: Thu, 27 Sep 2007 14:40:39 -0500Subject: RE: [scrumdevelopment] Why points are lame...I have educated him and he understands the concept. He justtries to break it down too far. He assumes if we average 35points per 2 week iteration, that means we can do 3.5 points perday. In reality, we may have 2 different 5 point stories and oneof them takes 1 day and the other takes 4 days.Cancelliere*Sent:* Wednesday, September 26, 2007 9:27 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, sometimesharder), etc. You might try to educate him on what team velocityis 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 myCFO. He thinks that if Story A was 5 points and took 20 hoursthen if Story B is also 5 points, it will take 20 hours. I’vetried to explain that, over time, it may equal out that way, butyou can depend on it being a direct correlation. I’mconsidering 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.Of *Nicholas Cancelliere*Sent:* Monday, September 24, 2007 8:11 AM*To:* scrumdevelopment@*Subject:* Re: [scrumdevelopment] Why points are lame...I don't agree with the statement about "if you're using hoursthen you're already using story points." This confusion betweenstory points = duration is how this thread was even started. Youcannot equate Story Points to a duration, if you are then you'rereally just calling an "hour" by some other name, which missesthe concept completely.Story Points are an estimate of size and complexity -- they don'tcommunicate duration.When you use hours for estimating you're estimating the duration,how long it'll take to get done. That could change based onthe 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 mostof 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 youhave astory that takes 60 hours, and that there are only 40 hours leftin youriteration (from a planning point), and he goes around the roomadding uppeople/weeks, and says. Oh no. I see at least 100 hours left.--Nicholas Cancelliere, CSM/CSPBusiness Analyst, InCircuit DevelopmentP Before printing this, think about the environment.---Nicholas CancelliereAustin, TXP Before printing this, think about the environment.--Nicholas Cancelliere, CSM/CSPBusiness Analyst, InCircuit DevelopmentP Before printing this, think about the environment.---Nicholas CancelliereAustin, TXP Before printing this, think about the environment.------------ --------- --------- --------- --------- --------- --------- ------Enter here. Win tix to see Crowded House live at the Greek Theatre,LA!---Nicholas CancelliereAustin, TXP Before printing this, think about the environment.Yahoo! Groups Links<*> To visit your group on the web, go to:<*> Your email settings:Individual Email | Traditional<*> To change settings online go to:(Yahoo! ID required)<*> To change settings via email:<*> To unsubscribe from this group, send an email to:<*> Your use of Yahoo! Groups is subject to:--Nicholas Cancelliere, CSM/CSPBusiness Analyst, InCircuit Development512-347-7400 x123 -- http://www.incircui t.comP Before printing this, think about the environment.---Nicholas CancelliereAustin, TXGot sugu on the brain?P Before printing this, think about the environment.
Find thousands of jobs online now! NEW jobsjobsjobs.com.au.
- I think getting into a controversy on whether or not we should have Sprint 0 or -1 or whatever (leading to discussion on Sprint -5 :)) is a bit sophistic.
Whatever you care to call it, I think it is essential to have it, to ensure that the development team is ready, willing and able to go. To a great extent it is the Envision phase, I think, which includes ensuring that the development team is approproiate to the task, that the whole general picture is understood, that everyone is singing from the same hymn book, getting all the ducks in a row and so on. There has been some discussion in this group previously about whether or not this pre-project phase (that is, pre iteration phase) should include decisions about and the adoption of development tools and standards. Some say this should emerge during later iterations, but I disagree.
Having undertaken this phase, the project team is then able to competently and enthusiastically (one hopes) into the iteration cycle of the project proper.
What Scott Ambler was talking about seems to me to be just this situation.
Sprint 0, Sprint -1, Pre-Project Phase, Envision Phase ... what's in a name, a rose etc .....
Date: Mon, 24 Nov 2008 11:42:54 +0000
Subject: [scrumdevelopment] Re: Sprint Zero
> > what he defines as "iteration -1" and "iteration 0"I have discussed the 'Sprint zero' matter a couple of times. The
> I do hear this kind of thing a lot, but it smells like procrastination
> to me.
> What innovation is next, the 31 day Sprint?
drawbacks seemed higher than the benefits:
- Sprint zero does not produce working code
- Sprint zero takes away the sense of urgency
- Sprint zero leads to a misunderstanding of Scrum
- Sprint zero disappoints stakeholders
Whenever you need to set the stage before you can actually do Scrum,
don't call it a Sprint or iteration. Once you are in a Sprint, you are
doing Scrum - so the first Sprint is supposed to be Sprint One
- deliver working code
- refine backlog items / user stories
- figure out the architecture outline
- make stakeholders happy
My regards to all the poor teams out there who are still in Sprint
Sign up for the Hotmail Road Trip today. Your dream beach house escape for summer!