52789Re: [scrumdevelopment] Re: Story point estimating - ideal time vs relative scale
- Oct 7, 2011Hi all,
Now this is getting interesting - the consensus I think until Reinert and Joe's posts was that (summed up by Mark) "Fundamentally, it doesn't matter what unit of measurement you use to estimate a PBI, as long as you apply it consistently."
I completely agree with that.
I understand where relative scale story points (instead of ideal hours story points) might have value on a psychological level, because they obfuscate the fact that we're actually talking about time, allowing developers to relax and give estimates free from the feeling that they're going to be tied to some time measure. (even though they wouldn't be if we were using ideal hours, because everyone should know ideal hours != real hours).
My problem comes when people try to make claims for relative scale story points that are bigger than that, because as you admit Joe an RSSP always resolves to time - e.g. "this team can do about 20 story points per 2-week sprint"; so if there are 120 person hours in the sprint, each story point is 6 hours.
When someone imagines the effort involved in building a registration form, for example, they're doing it in terms of time (or if there's any other variable, we're probably not interested in it). Whatever scale they decide for 1 point resolves to some measure of time.
So it's essentially the same thing, but with RSSP you're just not admitting the underlying "exchange rate", which is there nonetheless. So there's no advantage of RSSP except for that psychological mechanism (which only prevails for those developers who don't get around to making the conversion in their own heads).
All the advantages and disadvantages of RSSP are the same with ideal hours - e.g.:
- "people won't agree what an ideal hour really means" - people also won't agree on "how long it takes to build x"
- from the rapidscrum slideshow: While Accuracy with Precision is desirable, Accuracy is the more valuable of the two. - Ideal time story points can be just as imprecise and accurate (especially if used on an exponential scale for estimating the product backlog)
I realise this is all a bit philosophical. I'm happy to try RSSPs out on the basis that hiding the fact we're really talking in the end about ideal time, is helpful for people's frame of mind when estimating, and perhaps when working too ... I just don't like it when claims are made for them, that are just as apt for ideal time, and when the fact that they're really the same thing (except perhaps on that psychological level) isn't acknowledged.
Cheers and have a great weekend... :)
Mike Cohn on ideal time story points:
My preference is to treat a story point as an ideal day of work. We rarely have these ideal days, but thinking
about stories in ideal time offers two advantages. First, it is easier than estimating in elapsed time. Estimating
in elapsed time forces us to consider all other possible impacts on our time, such as the all-company meeting
on Tuesday, my dentist appointment on Wednesday, a few hours a day for answering email, and so on.
Second, estimating story points in ideal time gives our estimates a slightly better foundation than when they
are estimated in entirely nebulous units.
We use man-days as a basis for all time estimates (although we
call it story points). Our lowest value is 0.5, i.e. any task that is smaller
than 0.5 is either removed, combined with some other task, or just left
with a 0.5 estimate (no great harm in overestimating slightly). Nice and
simple.On Fri, Oct 7, 2011 at 4:50 PM, Joe <jhlittle@...> wrote:
I would DEFINITELY do story points.
Ideal hours do not actually communicate effort well (people won't agree what an ideal hour really means).
People are terrible at estimating time. Relative size/complexity gets estimated much better, and is much less likely to be skewed (usually under or over estimated).
Story points comes back to time as soon as you declare "this team can do about 20 story points per 2-week sprint".
Only the output of the team is meaningful...THAT's what we need to know, and then we need to know how to fill (but not over-fill) that capacity of the team, each sprint.
QED: Story points. (Well, the short version of the case.)
Don't ask them to agree to do story points. They have no experience, their answer is not meaningful...at least until they have experience. Say, "we're gonna do this new well-established technique." And give it at least 4 sprints. You can tell them it's an experiment and if is terrible after 4 sprints, we'll change it. (It won't be if anyone is professional around there.)
You might need a good coach to have the authority and the detailed experience to make it work better from Day 1. Seems expensive, but it is not compared to the alternative.
--- In firstname.lastname@example.org, "Reinert" <rekahm@...> wrote:
> There are a lot of advantages if you go for using only story points in your estimation of user stories. I.e. abondoning hours / time totally in all your estimates including (developer) tasks. If you are interested in more information, please check out www.rapidscrum.com. The link "AgileIndy Presentation: Hours are Dead" under "RESOURCES" gives you some more information. I've used many of the techniques he is describing and though they are quite unfamiliar, they are very powerful.
>> --- In email@example.com, Michael Jones <michaelhardwinjones@> wrote:
> > Hi,
> > We're rolling out an agile process in my company, where waterfall processes
> > have been used up to now.
> > I've been involved in a couple of discussions/debates with various folk here
> > (a product manager and a fellow PM) about the units developers should use to
> > estimate user stories in the sprint planning meeting. Specifically whether
> > to use ideal time (e.g. "1 ideal hour"), or relative scale (e.g. "about the
> > same as that registration form we did").
> > I have my own views, but what are your thoughts? Are there any stand-out
> > benefits of either in your experience? Should we throw it as an open
> > question to our developers?
> > Thanks,
> > Michael
- << Previous post in topic Next post in topic >>