Re: User Stories Opinion
- Adam, see below:
I totally agree that they should spend less time estimating, but I don't know how any organization can execute well without some sort of estimation process in order to set customer/stakeholder expectations appropriately. Maybe your team has a ton of leeway here. Maybe someone higher up does rough estimates without much of the team's input and the team is never held accountable to deadlines(though the 70%+ number seems to imply otherwise), I obviously can't speak to your experience there, but I'd be very interested how you can set expectations without estimates of some sort.
Any ScrumMaster that let's a team spend 70% of their planning meeting overanalyzing estimates is not doing a very good job of being a SM, IMO. That's a pretty bad smell, which means there are several solutions depending on the true cause of the smell. Much of this estimation time can be better handled inside of backlog grooming sessions or Sprint Preview Meetings. You can read my suggestions on preview meetings here:
_The Case for Sprint Preview Meetings_
IME, when a team does a good job of executing Sprint Previews (aka backlog grooming), very little time is spent estimating in the planning meeting. That holds even more true if the team does a good job of Release Planning. So far I've observed that the magic number of times to discuss a story as a team is about 3. Once at a Release Planning meeting or backlog grooming session, once at a Sprint Preview meeting, and finally at a Sprint Planning meeting, where each discussion gets more detailed and more deterministic as to what truly defines the story. If done well, VERY VERY little time is spent estimating in the SPM.
>I can't really argue with you too much there, but I hope when you say "I am effective" and "I am wasting my time" you're really meaning "the team" instead of "I". I'll assume you are. My only other point here is that when you deviate from Scrum to such a degree, it may be unhelpful or even downright dangerous to try to use other parts of Scrum as a software development framework.
> That might be true. It's in The Guide. So, if we ignore any historical
> notion of what Scrum might be and simply take Ken's word for it then
> you are right. Personally, I am less interested in whether I am doing
> Scrum and more interested in whether I am effective and whether I am
> wasting my time.
> > Do I have that much right?Ok, then my opinion on that theme is:
> Yes ...
1. I believe the technique you describe is an estimation technique, and I don't think I'll change my mind on that. The minute you extrapolate your (historical)measurement in an effort to set customer/deadline expectations in the future, that's an estimate, IMO.
Here is a definition of estimate I found at reference.com:
1.to form an approximate judgment or opinion regarding the worth, amount, size, weight, etc., of; calculate approximately...
I also believe that when someone decides that a story is "small" or even "too big to fit within a sprint", that is an estimate as well.
2. What sent me 'round the bend was this comment from Steve:
> .I think that's why I'm starting to join the "don't estimate them" crowd.What I took that to mean was that stories are never estimated in any way, to which I replied I don't know any org that can do well without *some sort* of estimation process to set customer expectations. Steve might have meant "don't estimate them[Using planning poker and story points]". That's the reason I attempted to clarify, although my attempt at clarification might have been not so good.
> I don't know how any organization can execute well without some sort of estimation process in order to set customer/stakeholder expectations appropriately.When I used the term "estimation process" here, I was not speaking of story pointing or any other specific estimation technique, just that *some sort or type* of estimation technique is needed.
3. I see your technique as another estimation technique. To me, this is the real beauty of Scrum as a framework. The Scrum Guide says that backlog items are estimated, but it doesn't specify a particular technique for doing so. Your technique, IMO, is an estimation technique that was probably grown from the three pillars of Scrum theory: transparency, inspection, and adaptation. In my mind, it is just another candidate in the pool of other techniques that we discussed.
4. Though I've never used your technique(caveat), I think I could see some situations where it would work really well and some situations where it might not work so well. You've described some actual observed evidence of where it worked well and why. I respect that. The technique is highly attractive in my mind, especially for certain situations. Like all techniques, I'm sure it has its advantages and disadvantages in different contexts/situations. Thanks for throwing another handy tool in my toolbox.
I'll leave it at that for now. Thanks again for the excellent interchange of ideas.