Planning Poker - Agile method

Manach

I am wondering what are people's opinion on Planning poker. This has been introduced as a means to scope and estimate time so I'd be curious of experiences of this

"
Planning poker, also called Scrum poker, is a consensus-based, gamified technique for estimating, mostly used to estimate effort or relative size of development goals in software development. In planning poker, members of the group make estimates by playing numbered cards face-down to the table, instead of speaking them aloud. The cards are revealed, and the estimates are then discussed. By hiding the figures in this way, the group can avoid the cognitive bias of anchoring, where the first number spoken aloud sets a precedent for subsequent estimates.
" - https://en.wikipedia.org/wiki/Planning_poker

.

Idleater

We use it in my current place and I have used it for the past 15 years or so in previous jobs with varying degrees of success.

At its simplest it works very well after a few sprints/months when the team has gotten used to the baseline and estimating and learning from incorrect estimations. T-Shirt sizing is also useful in pre-refinement.

At its worst I've had "the business" extrapolate projected delivery times and resources based on early sizings and compare different teams "20 points" as equal. When the latter happened I resized my backlog to multiplying each value by 5 which screwed up the manager's excel spreadsheet nicely.

The_B_Man

I've done it in 2 companies. One as a graduate, and one when I joined a team where I had no prior knowledge of the product.

As a graduate, I had written very little code and had little to no understanding of the product. I was then put in a "poker game" with another junior, a team lead, a tester and a very good dev with 15+ years exp who knew the product well. Basically the poker went "we just go with what the very good dev says". Literally a waste of time. If I said a number, then the guy who knew what he was talking about would say "actually, thats a 4" or whatever.

Similar in the other job I used it. One or two experts who just decide what it is, while giving the illusion that the team are contributing.

So I suppose it could work, but only if everyone in the room knows the product very well.

14ned

The_B_Man wrote: »

Similar in the other job I used it. One or two experts who just decide what it is, while giving the illusion that the team are contributing.

So I suppose it could work, but only if everyone in the room knows the product very well.

My current contract also is using it which is my first contract to do so.

We do it slightly differently - we all vote in private for one of the Fibonacci numbers, and the scrum facilitator chooses a value, optionally raising it for discussion if they think it appropriate.

The real point of points estimate is to determine how vaguely understood a problem is by the whole team. If everyone votes the same value it's usually well understood, and team members can easily substitute for one another. If there is a huge variance then probably only the domain expert should do the story. You then project plan around that accordingly.

Empirically it is well known ultimately none of the process actually matters in small teams where team culture is the real determinant of productivity. The very best team in Adobe back in the day had no formal process at all, they were just superb at anything they touched. You'll find the same about most of the top teams in the big multinationals, they don't worry too much about process, they just get on with things.

Big teams are though completely different, and process matters a ton with those.

Niall