Planning Poker

BillWoodruff

I recommend the I Ching. Just today I asked it: "Should CodeProject upgrade its hardware before installing Windows 10 ?" [^]; the reply was Hexagram 18, "Ku," associated with "repairing the damage:"

"Winds sweep through the Mountain valley:

The Superior Person sweeps away corruption and stagnation by stirring up the people and strengthening their spirit.

Supreme success.

Before crossing to the far shore, consider the move for three days.
After crossing, devote three days of hard labor to damage control.

What could be clearer than that, Chris ?

«I want to stay as close to the edge as I can without going over. Out on the edge you see all kinds of things you can't see from the center» Kurt Vonnegut.

Chris Maunder

OK, I'm ditching the poker chips and grabbing some hex's

cheers Chris Maunder

Duncan Edwards Jones

In a more serious note, what I have done before that did work at the start of a project was a visualisation exercise "This project will have failed in 2 years time and we will be down a post-mortem. What will we be blaming"...it helped draw out some project risks we hadn't taken seriously enough yet.

Johnny J

We used to, but the last year or so, we've abandoned the scrum method for kanban. Don't miss the planning poker at all...

Anything that is unrelated to elephants is irrelephant
Anonymous
-----
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-----
I'd just like a chance to prove that money can't make me happy.
Me, all the time

Lost User

Yes We use it reasonably informally (v small teams) but it works really well to get through estimations quickly - as ling as there's a scrum master to move things along when the devs start wanting to know 9,000,000 things about a tiny backlog item when they all agree anyway it's between a 2 and a 3.

PooperPig - Coming Soon

Ender Yemenicioglu

Yes we are doing it during the sprint planning with days as unit. We are a team with 5 developers and it works fine. It is also good to enhance the quality of the bug/issue description. If we cannot estimate a bug, it means it is not good defined. If we estimate a bug for more than 5 days we understand we should split it, and so on.

svella

We did at my previous company - IMHO about as effective as the magic 8-ball.

snorkie

I've done it, but found the whole story point thing a mess. We ended up equating 1 point to 4 hours of work. But I always tried to call out 4 or 6 :laugh:

Hogan

RobertHarris

I do, we use it every week (refining stories one week & planning the next) As a Scrum Master it is useful in as much as it allows me to estimate the work my team can complete in a two week sprint. Sometimes it works really well, other times we over/under estimate, but it all evens out. Using poker and making sure that the team have a refined backlog that covers one and a half to two sprints of work allows me to make sure the team are fully occupied. The second part to the Poker is making sure you get your velocity right for the team (another estimation) as giving them too much work is demoralising and giving too little means you are re-planning too often.

SeattleC

I used planning poker for a few months. I didn't find it offered much advantage over just talking about how long things would take. We never understood why some numbers were on cards, and others were not. It wasn't powers-of-two or fibonacci. We were told not to equate numbers to days, but nobody could make estimates unless they did equate numbers to days. There was endless confusion and disagreement on whether it was or was not possible to consider tasks that took less than one day. Could you realistically schedule two half-day tasks in one day, or would unexpected add-ons prevent you ever succeeding at this? The scrum master would beat us up if we estimated too high, so the estimates were always too low. We totalled up the number of engineer work days, and always scheduled this many days of projects, so we always ran over. We had sixty minute standups where the team watched the scrum master update TFS. We never looked back to compute our velocity. The team all knew we were scheduling too much work, but we weren't allowed to change the process. We were agile in exactly the same way as a rhinocerous in ballet slippers.