OK, let's go ahead and get started.
We're going to talk about agile estimating this afternoon.
Actually, that's a little bit of a mistake.
I'm going talk agile-estimating.
You're gonna do it, OK?
So we're have a lot of exercises interspersed in this one.
And I know we have full day like this.
It's really hard with these one-hour sessions to do much actual hands-on or activity type of things.
But we are going do some of those in the session in particular.
So I want to get you to make sure you have some practice estimating.
So here's our agenda.
Here are the four topics we're going to talk about.
Start out with kind of what is agile estimate and planning?
What are we after here when we call an estimator planning approach agile?
Second thing we'll talk is something called story points.
We'll talk about something called ideal time.
These are the two units that agile teams use for estimating.
They'll use one or the other, story points or ideal-time.
Then we'll get a chance to practice some estimations with a technique called planning poker.
So I'm going to want you to get the chance practice this.
We've got three exercises, I believe, interspersed through these four activities.
Let's see what agile planning is all about.
Agile planning is about separating the planning process on projects into two layers.
We're gonna have one layer of planning, estimating planning at a high level, where we plan something like a release or a three month time horizon,
a six month horizon.
Even pretty successfully up to about a year out into the future.
So we're going to have approach that we use for that longer term planning and then we'll have a second approach that we use when we're planning what Scrum
teams call a sprint, what other Agile teams might call an iteration.
So two different types of estimating and planning going on.
We're going to plan our projects at two levels.
What we'll start out talking about is this product backlog thing over here.
A product back log on an Agil project is meant to be the high level features.
So if we decide to compete with Excel, we're going to write a spreadsheet product.
We're gonna have high-level features like add pie charts, add spell checker, or add mathematical formulas, right?
Add text string-oriented formulas.
Things like that.
Be able to format cells for currencies.
So those will be the type of things that we would have as features, big items on a product backlog.
Some of you will know those might be called user stories on an agile project.
So that's what we're going to be talking about right now is how to estimate those type items.
What I'd like to do to start with is to have you get a little bit of practice estimating something.
what I would like you to is estimate two things.
I like have to you estimate how long it would take to drive from right here to downtown Paris.
Let's go to the Eiffel Tower.
Might as well go somewhere scenic.
So let's to go the the eiffle tower.
I'd like you to estimate driving from here to there.I'd also like to you estimate how long it would take to read the last Harry Potter book.
Now don't cheat and look it up on Google Maps or Amazon or something.
Because there's no test coming here.
I don't care about your answer.
What I care is that you learn something about real-world estimating.
Learn something real world estimatting here, so we're going to use these as a couple of real word activities.
OK?
I think the best way to do this is going be to this in small groups.
So I'll let you kind of turn backwards and forwards and stuff and form up into just some little discussion groups and think about it.
And I'm not going insist that come up with an exact mandated answer, consensus answer for your little group of five or six people.
but we're gonna do a couple exercises later where groups are gonna be necessary.
Wouldn't really need to do this in a group, but it'd be a good way to start out as some groups, okay?
So I'm gonna ask you to estimate these in groups.
While you're doing that, I wanna pass around a sheet of paper that we'll use for exercise later today, later this afternoon.
So go ahead, estimate those two things.
Driving to Paris, Harry Potter book.
I'll pass her on some sheets of papers for the next exercise.
Okay, so give that a try.
You don't need to do the sheet of paper now, that's just for later.
So just estimate these two things for now.
Okay.
Give you a lot of time to talk about that, but enough to just get started here, perhaps.
Somebody shout out an estimate for Paris for me.
Help me out.
How long do you think it's going to take to get to Paris?
Two days, 20 hours?
A week?
I haven't thought about it.
Maybe that's the scenic route.
Plenty of places to stop.
I guess it depends how we get down to Copenhagen or something.
Take the ferry.
All right.
Somebody give me an estimate on that.
Ten points, okay?
So we got somebody who knows where we're headed with the points here.
And that's actually an interesting point to raise here right now.
Telling a boss or customer, I'll be done in ten points doesn't help, right?
Tell me, oh I will be reading the Harry Potter book in 650 pages.
Doesn't help, right?
So that may be an intermediate step.
That's part of what we're gonna build up to here.
We're going to use this as an immediate step, perhaps thinking about how many points something is.
And I'll explain what a point is, I know we don't all know right now.
Let me get another couple estimates on the Harry Potter book.
Anybody over here Harry Potter?
15 hours.
20 hours?
Let's get one more from over there.
A year.
I can beat that.
I've been reading the fourth book for about four years.
The way you might have come up with one of these estimates is you thought about having done something similar.
And I remember when I read the fifth.
That was when it was on holiday.
I was here and it's about a week.
Probably read two hours a day, I'm going to say 14 hours.
So you might estimate by analogy, by comparison to something else.
I've never driven from here to Paris, but I remember the one time when I drove from Trondheim down to Rome.
That's longer, so let me subtract a certain amount on each end.
Estimation by analogy, it's a good practice.
Another thing you might have done is you thought about the size of the work.
I'm just gonna pick some easy math here.
You might have said the book is 600 pages, looks like about 600 to me.
I bet I read 40 pages per hour, 600 divided by 40, I am done in 15 hours.
All right, so you might've done some math like that.
In doing that, what we'd be doing is something like this.
Estimating the size of the work as a single step, deriving the duration as separate step.
I teach a full day class on estimating.
When I do, I tell that class there's five words I want them to memorize.
I'm going to give you right now for free four of the words.
They're on the top of this screen right.
Now I don't know if the fifth word will come up today.
Maybe you got to take the class just to learn that fifth.
But four other words, 80% of whole class that I am teaching when I teaching estimator class for a day, the benefit is to get people to realize estimate
size derived duration.
Do these as separate steps.
The Harry Potter book is 600 pages.
That's an estimate of size.
Driving down to Paris is, I don't know, 2,000 kilometers.
This takes some 3,00 kilometers, right?
I take some guess at how big that is.
And then as a separate step, i will derive the duration.
I might derive duration by reading Harry potter for one hour.
Okay, in one our I read 40 pages, do the math, and I'm done.
Right?
Those of you who know Agile will know we call that something called velocity.
I might start out the drive to Paris.
First hour's not going to tell me much, because I'm going be sitting in my car on a boat.
But the second or third hour, I may start to get enough data that I could figure out, OK, here's how long it's going take.
So we're going estimate the step.
We're to drive the duration.
Now, we want to talk about two units.
I had them up there earlier, Story Points and Ideal Days.
I don't want to introduce either one yet, so I'm just going to toss up an example this way.
We might think about the number of kilograms a project is.
Now, this is totally silly, right?
Weigh the spec, and it's 300 kilograms.
It would be a very big spec.
We find at the end of the first sprint, the iteration, we've done 20 kg.
We could divide that out and say we'll be done in 15 iterations.
That's the concept.
I know it's silly with kilograms.
Now this idea of estimating size-deriving duration is not new to Agile.
I wish we agile people had made this up.
If it wasn't me, I'd wish it was one of my other agile friends, Esther Derby who was in here earlier, Bob Martin who's giving great talks at NDC this week.
But it's been around since the traditional days.
In the tradition days, we've had alternative approaches to estimating size, though.
We've thought about things like lines of code and function points.
Now, we can all make fun of lines of code as a measurement.
We know it is a bad measurement, but it's literally true.
IBM, I think it was in the 70s, actually offered a bonus to the programmer who wrote the most lines a code.
This sounds silly today.
So lines are code, not a good measurement of size, But it a start.
If, for example, I asked you to rewrite a program for me and I said, you could rewrite one of two programs.
One program is 100 lines of code, the other program's a million lines a code.
And we all know we choose the 100 line program, right?
So lines of code, not a good measure, but I mean, it's something.
With a gross margin of error, that's a start.
So it was there.
It was OK.
Function points, something that we tried in traditional software development.
function points were meant to be a measure of the number of inputs and outputs and data tables accessed, things like that.
Well, the more inputs now outputs to a program the bigger the program is.
These are measures of size.
They didn't work out too well.
In Agile, we do it a different way.
We have these units, story points and ideal days.
I had two different units.
So I want to start out with storypoints.
Let's see what storypoint are all about.
Storypoints are a relative measure of size.
They are absolutely an estimate of how long something will take.
Some people try to make story point harder than they should be by renaming them.
They'll call them complexity points.
Maybe story point sounds too silly.
Sounds like something you do when you're eight or something like that.
So it's got to sound fancier.
Let's call it complexity point.
And this is a mistake.
This is mistake, I don't want you to do this.
Story points are still about how long something will take.
Complexity is factor, but it is not the only factor.
Now let me give an example.
Suppose we go outside.
It's a beautiful day out there.
I took a chance during lunch to walk out and just enjoy the day for a few minutes.
So we got outside, and there is a building over here on my right.
And I point to that building and say, that build will take us one unit of time to walked to.
Don't mean one minute or one hour, just one of unit time.
That building, over there, is about twice as far, it's going to take twice long.
The building will takes two units of times to get to, We're estimating time.
Now one of the things that's nice about story points is that that relationship is true.
One unit of time, two units of times to get to that building.
For you, you're going to walk there.
You're able-bodied, and you are going walk over there, I'm on crutches.
I have to hobble over on my crutches.
Well, even on my crutches, that building will take twice as long as that.
So one of the advantages here to story points is they let people or teams with different skill sets put the same relative numbers on things.
I like to run.
But I'm a horrible runner.
Suppose one of you is a good runner.
I'm a horrible runner, you and I go out to the start of a trail.
And I say, that trail's 10 minutes long.
You, a much better runner say you're crazy.
It's a five minute trail, and so we argue.
Five, 10, five, ten.
There's nothing you can do to convince me it's five minutes.
Oh, I can't run it that fast.
Maybe I could convince you to take 10 minute, but that's not a real good answer, right?
Maybe we agree on seven and a half.
That's probably the worst possible thing.
Now we got an estimate that's no good for either of us.
So we keep arguing, 510,510. We keep going, and you eventually say to me, Mike, it's a five-minute trail.
It's one kilometer long.
I say, you're right.
Its one-kilometer long, going to take me 10 minutes.
Soon as we put a size on it, we could agree.
And then we look at some other trail, And I'm looking at that trail thinking, wow, that one's going take twice as long!
That trail's gonna take 20 minutes!
And you're looking at it thinking, wow, that trail's twice as long.
It's going to take me 10 minutes.
Well, we can both agree to call that trial a two.
If the first trail is a one, the trail a is two, right?
So story points are still about relative size, not about complexity.
But I said earlier, complexity is factor.
Let me show you what I mean by complexity's a factor, remember our two buildings.
That building's one unit away, and that building is 2 units away.
Behind me is another building.
It's the same distance as the two-unit building.
The same number of steps, same physical distance, but there's train tracks.
And I've got to wait for the train sometimes.
I walk back to that, I go to the building, and every now and then there are train track and the trains going by.
and I'm stuck standing there waiting for a train to go by I don't want to call that one a two then, because sometimes when I got there it takes longer.
Sometimes it's a lot longer, so I'll call it a three.
It's the same physical distance as that building, but sometimes it takes longer, so I'm gonna call it a three.
That's not really an example of complexity, it's an examples of risk or uncertainty being a factor in our estimate.
Complexity, risk, uncertainty, things like that will influence our estimates, they're not what we estimate directly.
I had a class, give me a great example one time, a few years ago.
They said you have a two person team, doctor, brain surgeon, and a little kid.
I don't know why they're on the same team, but they are.
Brain surgeon and a little kid are on a team.
We have a two-item product backlog.
Perform simple brain surgery.
Snip, and you're done.
And lick 1,000 stamps.
Those two items, perform simple surgery, lick a thousand stamps, are chosen to take about the amount of time.
If you disagree, add or remove stamps and make it more stamps if you want.
Those two things should get the same number of story points.
If they're going to take the amount of time, they should the get same the number story point.
Because we make the simplifying but realistic assumption, the right person for the job will do the jobs.
We're not going wait for a little kid to finish school, finish university, finished med school.
Then do their brain surgery, right?
We'll be dead.
So the person right for job, will the do job.
In that case, those two thing get to same numbers storypoints.
Complexity is a factor, but it's not the only thing we're estimating.
Now with StoryPoints, I want the basic math properties to hold.
That always sounds complex.
It's like, oh my gosh, you're talking about math property in the afternoon.
All I mean is stuff like 5 plus 5 equals 10. I what the product owner or key stakeholder on a project to be able to look at it and go,
OK, my team tells me there's room for 10, what do I?
Oh, no, this one 10 point story.
No, I don't.
I want these 5 2s.
No.
no, no.
i want this 1 5 and these five 1s, right?
Anything that adds up to 10 should be about the same size.
That's all I mean by basic math property you should hold.
5 plus 5 equals 10. Either of those should take the amount of time, OK?
These are weird.
Story points are very, admittedly, weird I'd like to have you leave here thinking they're not so bad, though.
So what I want to do is if story points or weird, I wanted to you do something even weirder.
We're going to estimate in zoo points.
What I'd like to have you do is, in the brutal groups you were in before, maybe adjusted by new people who have come in,
or left, what I would like you to do, is estimate in zoo points.
Where a zoo point is a combination of how much of the mass and the volume of an animal.
How much animal there is.
Now a giraffe is pretty tall, but they're kind of skinny things, compared to something like a rhino.
So how many of animals there are.
Mass and volume somehow combined together to make up a total zoo-point.
So talk about this in your group.
Here's eight zoo animals for you.
See what you can come up with in terms of zoo points for those eight animals.
May not have given you enough time to do the whole thing there, but good enough to at least kind of start to get a feel for this.
Did any group get far enough along that we can start use your numbers just as an example here?
Yeah, thank you.
What did you put on our first guy, our lion?
Okay, so lion a one, everybody okay with that?
No?
Woo.
Yeah it's hard to be wrong on the first one.
That's actually a key point, right?
You can only be wrong here in comparison, when he says Lion's a one and Hippo's half.
OK, now we got an issue, but you can't be on the first one.
So let's go with Lion.
We got Lion as a 1. What about a kangaroo then?
OK.
so we're saying here, Lion and Kangaroo about the same overall mass and volume.
Seems OK to me.
You never see them together at the zoo.
I guess if they were together, one would be eating the other.
That's why you never seen them.
What about rhinoceros?
OK, so rhinosceros of five.
Rhinocerous about the same as five lions.
Picture five lion together.
Maybe a little bigger, I don't know.
Seems close.
Bear.
So a bear is a little bit smaller than a rhino.
I was thinking about those Australian guys.
Koala bears.
You're probably thinking of a big ice bear or something, a four.
All right, so here's one of the key things here.
Did everybody know there's multiple sizes of bears, right?
Everybody knew there were multiple size of bear, all right.
So I know koalas aren't really bears.
They're marsupials, whatever a marsubial is.
But I don't know.
I just know they are one.
One of the key things to do here is, if you have something like this, what I gave you was a vague requirement.
I give you a big requirement, one of best things do with the vague requirements, ask your product owner for clarification.
Nobody asked me, and I know it's kind of hard in a group like, this nobody asked, hey what type of bear?
Another thing to, do and here's actually I will give, you the fifth word that I teach in my one day class, use a range.
Range would be that fifth, word.
Anybody remember the first four words?
Something to do with size and duration, right?
Estimate size-derived duration.
What I'm talking about there is estimate how long it's going to take to read Harry Potter by estimating the page count, then deriving the duration by actually
reading for an hour.
Estimating size, derived duration in separate steps.
Fifth keyword of advice, use a range.
So it might have been better off with a bear here saying something like, oh, there's those koala bears.
Let's go with one to four.
Now I won't go through the rest of the numbers here, but I want to mention I forgot to add one animal up here.
And I don't know if he's really a zoo animal.
But I did want put one more up there and forgot type him onto the slide.
Blue whale.
Anybody have an idea what you want?
One gazillion.
There's always a good estimating technique to use a meaningless unit.
And hope your product owner doesn't know.
So I got to share with you an old joke then.
This is a joke you probably haven't heard, because this is joke that was popular in the US about six, seven years ago.
I remember we had President Bush six or seven year ago, and there was a job that he was getting briefed in The War Room that that his secretary of state
was debriefing him on some activity and said, well, you know, overnight we had some conflicts and we have three Libyans died and a Brazilian died.
And President Bush is really sad about these people dying and he goes, remind me again, how many isn't a Brazillian?
Right?
So use meaningless units as one estimating technique.
So this is what a story point is about.
A story is only meaningful in a relative manner.
Five is twice as big as two and a half.
5 is half of a 10. Story points are relative.
I made the point here about the blue whale to point out one key thing about being good at estimations.
No matter what unit you leave here with liking, I want you to be good estimators.
A key step in being a good estimate is to stay within about one order of magnitude.
We could have argued about this, and we could argue about is a tiger bigger or smaller than a lion, things like that.
But there's nothing we can do to put a number on Blue Whale.
It's just too out of the realm here.
All right, we're good in about 1 to 10, one-order of magnitudes.
If we get out one of order magnitude, We are no longer good estimates.
Plenty of studies that show this.
So you want to have the bulk of your product backlog, the book of requirements, whatever you're estimating, be in about one order of magnitude.
You get outside of there, start to get nervous.
Key tip in getting good at estimations.
Now this was probably hard to start with.
It's really hard to start with.
What do we call the first one?
How do get going here?
It doesn't bother me if this technique is hard start because it's easy to continue with, it is easy continue.
Suppose we had our numbers up here, actually let's go with it, what did you have on Tiger?
You had one on Hawaiian, Tiger is probably the same?
Two, so Tiger bigger than Hawaiian.
Okay, fine with me.
what would you put on cheetah?
Or how would you estimate cheetah, right?
You'd look at your other big cats, and you'd make an adjustment from there.
You might say, oh, yeah.
Cheetah's a little bit smaller than a lion.
Let's call it 3 fourths or something.
So we can estimate relatively gets easier over time.
The more items on your backlog, the easier it is.
Because you're not going back to first principles questions.
Your just looking for something similar.
I got cheetah estimated.
Now jaguar comes along.
OK, how big is a jaguars?
Oh, it's about the same size as a cheeta.
Whatever number I put on there, I'll put it on this.
So estimating relatively gets easier over time.
The other unit favored by agile teams is something called ideal time, Ideal time is the amount of time something will take if three things are true.
It's all that you work on, nobody bothers you, and everything you need is on your desk when you get started.
This is clearly why we call it ideal time, right?
This stuff never happens, all right.
But the point with calling it ideal time is to think about how long it would take if everything went well.
Isolate yourself from distractions, interruptions, everything else.
OK, if this is all I did, I could be done with this in three days.
If I drove from here to Paris, could I be there by tomorrow night?
Well, I'm not going to get there by tomorrow night.
I have to stop some bio breaks, some meal breaks.
So let me make it this long.
How long would something take if that's all we did?
The best example I can give for ideal time is to think about something like American football.
Now, I know everybody here has not seen that, so I won't use that one.
But if you have ever seen an American Football, start to kind of mentally switch this example to an America Football game,
and you'll see why it's such a great example.
I'm going to actually use my favorite sport, which most of you, for sure, have seen, basketball.
I love basketball.
So if we think about a basketball game, if I were to go to a baseball game and I tell my wife, I'm going to the game.
International basketball games is four 10-minute quarters.
I'd tell wife I am going the basketball, game I will be back in 40 minutes.
She's going to be a little mad when I come home two, two and a half hours later.
So that game is not going be 40 minutes long.
Clock stops, all sorts of things like that.
Now, football, this isn't the best example because the clock kind of keeps running.
But American football.
Those of you who have ever seen a game know the clocks stops all the time.
The American Football game has 60 minutes of actually playing time, players are running around for 60 minute, but the game takes three and half hour.
At a basketball game, they're running for 40 minute but they game take two hours.
So we can say the ideal time of a basketball game is 40 minutes, but the elapsed time is longer.
The elapse time, it's more like two hours.
So, we have a difference here between elapes and ideal times.
I might look at it and say my Monday work day has eight hours, my work week has 37 and a half or 40 hours but that's not what I'm going to get.
I'm going to come in to work, and I have to answer email, do all sorts of other things, meetings.
So there's a relationship, a ratio here between elapsed and ideal time.
They're not going be the same thing on a project.
Now when we estimate in time, this actually creates some problems, because sometimes your boss walks in and says, when will you be done?
Or I say, how long to read the Harry Potter book?
And you say 20 hours.
Wow, 20 hour?
You're going have your hands on the book for 20 No, no, I meant I'll be done 20 hours from now, because I also got to sleep tonight and things like that.
So we've got be careful with time as an estimating unit, Because sometimes the boss or client is asking for an elapsed time estimate,
and we're giving back an ideal time estimates.
There's a little bit of room for confusion there.
We've gotta make sure we are using the same unit.
This is back to that point about estimations, size, driving, duration.
Sometimes we were being asked for estimate of size and give back and estimate duration, so it causes confusion.
I like story points.
Most Agile teams use storypoints.
A couple of key reasons why I liked story point.
Story points are additive.
Time is not.
This is back to the example of you and I going out for a run.
And I say it's 10 minutes, you say its five minutes.
If we put your estimate on some things and my estimate other things, we can't add those up.
You're estimating in your time.
I'm estimatin' in Mike's time, they're not the same.
Story points are additive.
They let people with different skill sets use a common unit.
We can both agree that running that trail's one point, running out of their trail is two points.
Another advantage with story points is they help avoid a problem with what I call unit confusion.
Let me show an example of what mean by unit conclusion.
Suppose we have this.
I had this picture up here earlier.
We had a product backlog, and we had an iteration or sprint backlog.
If we look at that product back log on the left, we've got the 30, the 50, to 50. And then we run a sprint or iteration.
The team turns the work into the working iteration, And they estimate the hours they run the sprint iteration on their right.
When we get to the end of that first iteration and somebody says, When will we be done?
When we'll we done.
Well, let's do the math.
Let's figure out when we're going to be.
Done we figure.
Out how many hours are left on the project we add up the numbers on.
The left 50 50 20 and 20 that 30 is done so we just add.
Up the other four we said we got 140 hours left.
On the.
Project okay well how long does it take us to 140. Hours we.
Add up.
the Numbers on their right 12 plus 8 plus 4 plus 6 plus 5 we had that up it equals 35. I've obviously contrived the numbers here to make the math easy.
I divide 140 by 35, and I say we'll be done in four sprints or four iterations.
No.
It's wrong.
What we're doing there is bad math.
We're literally dividing apples by oranges.
All right, we are doing bad maths.
Those numbers on the left, let's not call those hours.
Let's call them hours we pulled out of the air.
Because a team, on average, is going to spend two or three minutes estimating those.
In a couple minutes, I'll show you how.
A team is gonna spend 2 or 3 minutes estimated those anybody who's ever done a Scrum or Agile project knows sprint and iteration planning,
long and painful.
So let's not call the hours on the right hours.
Let's call those hours we thought a lot about.
Those are painful We cannot divide hours, we pulled out of the air by hours We thought about, it's different numbers.
If you're experienced with adjunct, you might have noticed the little trick or the problem that's occurring here.
I have to be consistent in the units that I use.
If I say we have 140 hours left, that a true statement.
On the left it's 140. But I need to divide that by something.
And I don't divide it by the 35 that get by summing up the things on the right.
Anybody know what number I should divide by?
The 30 on left.
The 30 on the left turned into 35 hours.
But before I got into that work, I thought it was only 30 hours, right?
Well, before i get into the 140 hours of work I think it's 140. I bet it is going to expand too when we go to do it.
So we have to use consistent units.
Now when use story points here instead of hours or days, when you story point here, we change those to points, We're not likely to do bad math.
Somebody's gonna add this up, and they're gonna say, okay, when are we done?
Okay, let's add up the numbers on the left.
We got 14 left, how fast do we go?
Well, we can go 35 hours.
14 points divided by 35 is, whoa, I can't do that.
How about 14 point by three points?
Oh, it will be done in five sprints.
I maybe seem like I'm making an esoteric point here.
It's actually a key point, because when I see this, They're almost always one to two sprints late in delivering their project,
because work expands when looked at in detail.
That 30 later turns into 35. So I want to get a chance to practice estimating here with a technique called planning poker.
Planning poker is a consensus-based approach to estimatin, very loosely based on wideband Delphi approach, which came out of the Rand Corporation in the 1940s.
The idea here is our product owner walks into the room, reads a user story or product backlog item to the team.
Team members talk about it.
Each team member is holding a set of cards.
We'll pass out a bunch of card so you have some to do this.
Each teamwork is a holding bunch a cards with the estimates on there that we have pre-agreed to use.
Remember we're outside.
That building is one unit away, that building's two units away.
I point to another building off in the distance and I say, That buildings is 17 units way.
And you tell me, no it's not.
It's 18 units a way What a crazy debate.
17, 18, 17 18. Who cares?
We're not going to be right.
We can't distinguish those numbers.
They're too close to one another.
So we're going not to use both of those number.
If we pick one, we wouldn't use the both.
All right?
So the way planning poker works, each person has a deck of cards.
Each person listens to the product owner or key stakeholder.
The pick a number indicating their estimate.
all at once, the estimators turn their cards over.
if every estimator has the same number, write that number down.
we are done.
If we don't, the outliers talk about it.
They argue.
Here's why it's big.
No, here's it small.
Let's say we get them in the room, and they start estimating.
And we'd get, in this case, two fives and eight and a 20. I would ask the outliers, I'd ask Johannes, why a twenty?
Oh, this is going to be huge, i'm going have to do such and such, it's going be hard because of this.
and I ask Anna Ertrond, Why a five?
What's gonna make this easy?
And they'll tell us why it is gonna be easy.
The next round.
People change their opinions.
We get, in this case, three 8s and a 13. I'd ask Johannes again, come on, you're the high number.
Why?
Convert us.
Give us a reason to convert.
All right?
I was with a team recently in Atlanta in the US.
They had all 8's 113. The guy with the 13 gave the reasons.
In the next round, everybody switched.
So notice it's not a vote.
we don't, this in case say the 8 win.
You repeat until we come to consensus.
OK?
The consensus may be a little false.
A couple more rounds after this, Johannes may say something like, You want an eight?
Here's your blankety-blank eight.
He'll probably add something like, but remember this day.
Some of you have worked with him.
Reserving the right to remind us when he turns out to be right.
So I don't need him to go to his grave defending an 8. I do need to fold eventually and go, OK, you guys have heard me, I still think it's bigger,
But I'll go with an eighth on this.
We've got to get to team consensus.
Yeah, so the question is do I go to an average?
This is always a tough one for me.
I'm okay with you doing that, okay?
I totally am.
Here's the problem.
Each team has to figure out a way to come to agreement, right?
i don't want to be the one to say, hey, everybody in the world, here's how you should do it.
Some teams choose after three rounds, they pick the high.
Other teams after two rounds or three runs, the pick low.
other teams will pick average.
I do want to caution you a little bit with going with the average, because I think a big part of the benefit here is the fierce debate and the arguing
and trying to convince each other.
And some teams find it just too easy to just, OK, we'll just go with average and they miss out on a lot of debate.
It's not that the debate is that great, it's that debate what brings out all the hidden assumptions.
I think it's big because we have to do this.
Oh, I hadn't thought of that.
You're right.
It is bigger.
And so I don't want to cut that debate short.
So if you feel like your team is still having good debate, this is a quicker way to end.
I'm fine with it.
Right?
So I want to give this a practice try here.
Here's my recommendation, two tips.
One tip and one recommendation.
Think of the numbers as buckets of water.
OK?
I'm going to you cards here, you can see the number I am going give you up here?
For example, an 8 and a 13. Maybe even better, buckets a beer, right?
If I give an eight and 13, and you've got a backlog item, if you want call a 10, The 10's got to go in the 13, right?
Imagine you have an 8-liter bucket and a 13- liter bucket.
You've got 10 liters of water.
It's gotta go into 13 liter buckets.
So we're gonna have a slight rounding up, a slightly pessimistic bias, we would call this in estimating world.
Slight pessimist bias here.
Now here's my recommendation on how to get started.
With the zoo animals, I didn't care.
There was not very many of them, it didn' t matter.
Here's recommendation in real world, look for a 2, Look for 5. Right?
Remember, we're only good about 1 to 10. I'm going to consider 13 to be close enough to honorary member of order of magnitude.
But we are only going across about one to 13. So look for a 2. Look for 5. Don't necessarily play planning poker on those.
Just somebody on the team says, that one's a two.
Okay, or you're crazy, this other one's a two.
Once you find your two, look for a five, something about twice as big.
Then kick in with planning poker.
So I want to give us a chance to try this.
We don't have a lot of time, we'll do this for about 10 minutes, so we will just wrap up for just a minute at the end.
I'm going to pass out a bunch of planning cards, I've got big boxes of them.
Everybody take two boxes, that way when you go back to your team, they'll have enough for eight people, plus we'll add extras up here.
But everybody take to boxes as we get these passed around quickly.
I've got your back log on the next slide, it's also what I passed it around, so you have it on a handout, because you might need to write some of the numbers down,
unless you got a good memory to remember them all, okay?
So, form back into your groups, look for a two and your five, while you're doing that, I'll pass around a bunch of cards,
everybody takes two decks out of, two box out here, OK, let's come back together just for one minute to wrap things up.
Apologize for taking it right up to our one hour limit.
Hopefully that went OK.
Planning poker is really tough the first 20 minutes or so.
So this probably didn't start to feel real good yet.
But I do encourage you to check this out as a technique back in the office.
I think this is a great way to do this.
Two last things here.
My got tired of not having a good answer for distributed teams a while ago, so I programmed up and got one of my My programmers,
to help me, we build a website for distributed teams.
You'll log in here, you get a private URL, and you can share it out with your team.
All the cards flip over at the same time, so nobody can cheat.
Makes it nice.
So check that out if you've got a distributed team!
I'm back here every three months or so doing training sessions for Programming Up to Clean.
If you're interested in Scrum or Agile stuff, I'll be back every few months.
Thank you all very much!