So let's talk about how to pull all these ideas together into an estimating approach that works.
The technique is called Planning Poker, and it's loosely based on the Delphi and Wideband Delphin approaches that date back to the Rand Corporation in
the 1940s.
In Planning poker, each estimator, which should be everybody on a team, is holding a set of cards that contain the numbers the team has agreed to use as
their estimates.
Normally this will be the modified Fibonacci sequence, but that's really up to team.
The product owner reads a product backlog item, usually a user story to the team.
The team and the productowner discuss the item.
Team members ask questions.
the Product Owner clarifies expectations.
This can be as short as a few seconds, but it can take as long as needed.
Once each team member has decided upon an estimate, they pull that card out of their hand, holding it so no one else can see it.
When everyone has picked an Estimate, the cards are revealed all at the same time.
If everyone is holding up the same number, we're done.
Write that number down as the estimate and move on.
But if the numbers are different, We discuss it and then estimate again.
Let's see an example.
During the first round, our estimators hold up a 3, 8, a 2, and a 5. At this point, I really want to hear from the outliers.
Why an 8? Why a two?
Anybody can talk, but in this case I would really like to know from Vadim and Anne.
Vadim might say, well, I'm the tester on this project and this is going to be really hard to test.
I need to build a new test framework, and so on.
Anne says, Well, Vadem is right.
My 2 is too low, so I am going up.
But I've programmed this type of thing before and it's not that hard.
So I m coming up, but not all the way to an 8. Anyone can talk at this point, but I especially want to hear from the outliers.
After anyone who wants to has had a chance to talk, each team member again picks a number from their cards in their hands,
and then all at once, the cards are revealed.
This time, let's say we get three fives and an eight.
At this time point I'd ask Chris with his eight to give us an impassioned plea for why eight is the right estimate.
I was with a team a little while ago that had all eights except for one 13. I asked the guy with the 13 why.
Boom, boom, Boom.
He gave three good reasons why he thought it was a 13 and on the next round, everyone switched to agree with him.
So notice this isn't a vote.
We don't say that the majority rules and pick a five.
We keep going until we get to a consensus.
The consensus may be a little false, but that's okay.
Suppose we go another two or three rounds, with Chris holding up an eight while the rest of us have fives.
At that point, I'd probably ask Chris if he thinks we've heard his arguments but we just disagree.
If he does think we heard him, he will eventually fold and hold up a five.
I'm okay with Chris folding.
After all, the difference between 8 and 5 isn't that great, and we're pretty far up the effort accuracy curve we saw a few minutes ago.
Now, if Chris had been holding up a 100 instead of an 8, I wouldn't want him to fold.
If we are that far apart, we probably are facing one of two problems.
One, product uncertainty, which is the product owner saying something like, good question, better run that by some users,
it could go either way.
Or two, technical uncertainty.
which is when the team thinks that doing the user story will be easy if they use one particular technical approach, but hard if take another approach.
So whether it's product uncertainty or technical uncertainty, if the estimates are hopelessly far apart, put the story aside,
do the research, and then estimate the users story next week or whenever you get together again.
Or consider using a range if reducing the uncertainty will take more effort than you want to or can invest.
If team members ask the product owner what type of bear, koala bear or grizzly bear and the Product Owner can't say, your best option is to write down 5
to 100. One challenge with relative estimating is how to get started.
My recommendation is for team members to look at the product backlog and find something they want to call a two.
Don't play planning poker quite yet.
Just find a 2. Something small, but not the smallest.
I don't want you to waste time doing a bubble sort on your product back log, looking for the small item.
Instead, someone on the team points to one user story and says, that one's a Two.
Team members can argue if they disagree, but they keep at it until the team finds one user story that everyone can agree is a two.
Then, look for a five.
Remember, we're only really good across one order of magnitude, so finding a 2 and a 5 establishes us a good baseline across most of that order or magnitude.
I don't really care if you find a two and a five.
Maybe find one and five, or a 2 and an 8. Any of those is fine.
The idea is just to get a pair of numbers that everyone agrees on and then start playing planning poker.
I want to mention briefly that if your looking for planning cards, we do sell the cards at our cost on our website at store.mountaingoatsoftware.com Also,
we have a free website you can use for playing planning poker with a distributed team.
In the next video, We will look at some of the reasons why planning Poker works.