Re: [scrumdevelopment] User story estimation
All good points as usual. I'm glad you brought it up because I should have given a more clear "disclaimer" that the RRP technique is essentially described in the last handful of slides, and that the rest of the slides might be viewed as controversial or outdated, so I'm claiming nothing one way or the other about those slides. In addition, you have to remember that this is a presentation slide deck, so we're probably missing quite a bit of the context (I've been to the preso twice, so I have the more full context, but I also don't remember every last detail.)> . It seems he's using it to identify things that the team does not understand.
Yes, and... things where there is simply a large disconnect(estimate difference = more than one t-shirt size apart) between the PO and Dev Team. As I understood it, one of the main "disconnects" we're looking for there is something that the PO thinks is much easier to implement than it really is, and thus significantly affecting the ROI equation of value/cost. He's very careful to make sure that the PO estimates do not skew the Dev Team estimates. He refers to these large disconnects as anomolies, and lets a bit more discussion happen about each of them. He then rightly says that the Dev Team gets the last say on the estimate after the "anomaly" discussion.
IIRC, the first time I heard the preso, I was one of the people that encouraged him to make that "PO skewing risk" clearer and less likely to happen.
> To make it fair, can the developers express their expectations for feature revenue? :)Wow... that's an interesting point... and would be a very interesting exercise... seeing as how you could make the argument, in contexts where the Dev Team has a lot of domain knowledge, that the "anomalies" there should be discussed too! In that case, of course, the PO has the last say.
One other disclaimer... let's remember that this is a "Release Planning" technique, not a Backlog Grooming/Refinement technique. One would still do normal grooming on every story.
I also want to make it clear that, IME, the RRP as described, is really most useful(sweet spot) for the multiple teams/one product/co-located teams/lots of backlog items context. I have also successfully scaled/modified the RRP techniques down to a single large team(7-9 devs) with a couple of remote members(video conferencing). I'm not convinced one would ever need RRP with a smaller team with less (possibly larger) backlog items to work with in a Release Planning session. You could probably just use good ol' planning poker for those situations. So, while I've tried the "white elephant sizing" and similar concepts before, IME, they are generally much less efficient and effective than the other techniques mentioned in this paragraph. They are sometimes more fun, but not as efficient and effective in my view.-------
Professional Scrum Trainer
From: Ron Jeffries <ronjeffries@...>
Sent: Friday, June 14, 2013 5:27 PM
Subject: Re: [scrumdevelopment] User story estimation
Charles,On Jun 14, 2013, at 6:25 PM, Charles Bradley - Professional Scrum Trainer and Coach <chuck-lists2@...> wrote:
To scale to a large number of stories, I much prefer Lee Henson's Rapid Release Planning over the "put it on the wall/table approaches". RRP encourages individuals and interactions, teamwork, and collaboration, while allowing for "parallel processing" efficiencies. It also uses time-boxes, which help keep the process efficient:
(The main RRP technique is described in the last few pages)Can't say I'm very fond of that slide set. It seems to be a melange of every idea in Agile Planning, with a little something for everyone.One Particularly Bad Idea is the notion of mixing Must Have, Should Have, Could Have and Would Like into each Sprint.That strategy is demonstrably inferior to doing all the important things first. Its sole advantage(?) is that if you happen not to get something done you can say "well, we didn't really want it that badly anyway". Arrgh.The notion of the PO (cloud(!)) estimating things is also … questionable. It seems he's using it to identify things that the team does not understand. That's a good thing to accomplish, but I don't see why the PO estimating development time is a useful way to do that. To make it fair, can the developers express their expectations for feature revenue? :)