This doesn't help at all with prioritization, though you could probably do a similar activity with stakeholders assigning a business value estimate to each story and get a force-ranking of priorities.

I'm also not entirely sure how these slice against story mapping, which I understand more to be a visualization/exploration of the work required for specific features (and might be a thread hijack, so please point that out if it's true). Though I'd be very interested to hear thoughts on that as well...

-k

On Jun 14, 2013, at 11:07 AM, curiouschimp wrote:

Hi all.

I'd like some feedback on user story and task size estimation.

Is there a 'best practice' in using planning poker? Do you use all the engineers or a subset with domain expertise who will most likely be taking on the tasks?

Or those who are 'interested'?

I know that ideally, engineers should be full stack but the team has certain expertise they've taken ownership of.

I've done reading and I have my own conclusion but I'm interested in hearing more. There is a thought among the team to let an 'interested party' group do the costing, rather than the whole dev team.

... (going off topic a bit from the OP s question) I m not a big fan of such approaches(another similar one is called white elephant sizing) because, IMO, it

Message 2 of 11
, Jun 14, 2013

0 Attachment

> huge fan of the Planning Game

(going off topic a bit from the OP's question)

I'm not a big fan of such approaches(another similar one is called white elephant sizing) because, IMO, it limits conversations, interactions, and it takes to long because it is single threaded. It probably works fine in certain circumstances (small number of stories, smaller teams who can have a quick conversations and then move on without the need for more discussion, conversations not as necessary?, people need a break from the usual technique, etc )

When there is a fairly small number of stories, I much prefer efficient backlog grooming sessions with planning poker.

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:http://milehighagile.files.wordpress.com/2011/04/rapidreleaseplanning.pdf
(The main RRP technique is described in the last few pages)

I coach a similar "team collaboration, parallel processing" strategy for DoD workshops and retrospectives sometimes. Don't get me wrong, I coach and teach a variety of techniques, but I certainly do skew towards certain Scrum patterns when the context is appropriate.

This doesn't help at all with prioritization, though you could probably do a similar activity with stakeholders assigning a business value estimate to each story and get a force-ranking of priorities.

I'm also not entirely sure how these slice against story mapping, which I understand more to be a visualization/exploration of the work required for specific features (and might be a thread hijack, so please point that out if it's true). Though I'd be very interested to hear thoughts on that as well...

-k

On Jun 14,
2013, at 11:07 AM, curiouschimp wrote:

Hi all.

I'd like some feedback on user story and task size estimation.

Is there a 'best practice' in using planning poker? Do you use all the engineers or a subset with domain expertise who will most likely be taking on the tasks?

Or those who are 'interested'?

I know that ideally, engineers should be full stack but the team has certain expertise they've taken ownership of.

I've done reading and I have my own conclusion but I'm interested in hearing more. There is a thought among the team to let an 'interested party' group do the costing, rather than the whole dev team.

Below are some good responses from Steve and Jesse, I so I will +1 and add a couple of comments ... In Scrum, we shy away from titles -- so the real question

Message 3 of 11
, Jun 14, 2013

0 Attachment

Below are some good responses from Steve and Jesse, I so I will +1 and add a couple of comments

> Do you use all the engineers or a subset with domain expertise who will most likely be taking on the tasks?

In Scrum, we shy away from "titles" -- so the real question is -- who estimates on a Scrum team? The answer is that anyone can estimate on the Scrum Team, but the Dev Team has the last say on estimates, which means the Dev Team self organizes to decide how they express that "last say". A big part of self organization is that the Dev Team *creates AND executes their own plan.* IME coaching teams, planning poker seems to work the best for estimation, and the vast majority of the time, the entire Dev Team (Dev Team role as described by the Scrum Guide)
estimates, and no one else generally estimates.

> There is a thought among the team to let an 'interested party' group do the costing, rather than the whole dev team.

This is a hard statement for me to parse. Estimating is not "costing" (at least not exactly), and who is this "interested party group" you speak of? Are all members of the interested party group part of the Scrum team? If this interested party group is not comprised of Scrum team members, then why does the team want to let them estimate?

Note that, since we're on a Scrum list, I'm assuming you're doing Scrum -- but maybe you're not. If you're not doing Scrum, that would be helpful to know.

I hear you mention two separate things, task size estimation and userstory estimation.

For the story part, prefer the whole team, even though the 'domain expert' might think he knows everything it's good to have input from others to challenge the number. It also prevents people from guesstimating too low numbers, since they already know so much. Or people from forgetting the amount of work the updating of the automated tests, the test data or the deployment scripts is going to take :).

For tasks you'd still prefer the whole team, but when there is a clear indication on who will do the task (which could be a small, domain bound step in the story) then the 'domain expert' usually has more weight, especially when he comes up with a higher number. We don't usually do planning poker for tasks, since it's, in our case, an estimate in hours and not relative to another task as with user stories. You can do this when your tasks are small enough to be completed in about one day. Usually when a developer or a pair of developers picks up the task, they revisit the original estimation to make sure it's still valid, then update their progress at the end of the day (which usually means they close out the task). The most important thing we agree on as a team is that the story is small enough to be executed in one or two days.

I really try to get dissolve the idea of domain expertise as quickly as possible. One way to do that is to ensure that the entire team(not just the engineers) are part of the estimation process. By allowing the “interested party” approach, you are helping your engineers create silos. Not only that but you are enabling self destructive behavior as far as their own careers go.

One thing I really like to stress for those engineers is that each story is a team commitment, even if they expect to be separating into their usual silos. If nothing else, by estimating together, they can help other team members understand why they think their stories are the size they are...

To scale to a large number of stories, I much preferLee 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:http://milehighagile.files.wordpress.com/2011/04/rapidreleaseplanning.pdf(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? :)

Ron, 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

Message 5 of 11
, Jun 15, 2013

0 Attachment

Ron,

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.

To scale to a large number of stories, I much preferLee 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:http://milehighagile.files.wordpress.com/2011/04/rapidreleaseplanning.pdf(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? :)