Thank you for being here.
We're going to talk about planning projects.
Some of you were here an hour ago.
Were talking about estimating projects, made the point when we were estimatin' that we didn't do anything particularly useful.
we just put some points on things, we put story points of things.
In this session what we're gonna do is we gonna talk how to use those points or those size estimates and actually try to create a plan.
And we are gonna try and do it in a couple of fairly complex environments.
Now, I want to kind of put some context around this by saying that I think organizations plan at six different levels.
We'll see which levels the team gets involved in here.
But we have six levels of planning going on.
That's happening where you think it would be.
It's happened in the daily stand-up, right?
We come together.
Here's what I'm going to work on today.
Teams do sprint planning or iteration planning where they look ahead a couple of weeks.
We also do release planning.
I use the term release-planning to refer to looking ahead of a handful of months.
three, six, maybe nine or 12 months.
This is a weird word.
We're in this strange world right now, where releases are becoming smaller than sprints.
Years ago, if I was teaching a class like this, everybody in the room would have been in a mode like sprint, sprint sprint release,
sprint sprint sprin release.
I had a guy in a class I was teaching a couple weeks ago.
He releases seven times a day, on average, seven time a days.
So releases are becoming shorter than sprints.
I'm still a little bit stuck in the past here.
And I am using release planning to mean kind of medium or longer term planning, three, six, nine months, that type of a thing.
We also do product planning.
Product planning is kind about road mapping.
Road mapping, where are we going to be by the end of the year?
What type of release are going have in spring of 2013? Things like that.
Above there, we have portfolio planning.
What types of products are people looking to your company to provide?
And above there we company strategy.
Now, the Agile team is going to get involved down here at the bottom three levels.
The one we're going focus on today is gonna be that release planning level and trying to come up with some complicated situations for release planing,
this three, six, nine month type of plan, figuring out ways that we can effectively do this.
The way release and iteration planning glue together is this.
We have a release plan, which is looking ahead, in this case, I'm going to say seven sprints or seven iterations.
That might be as little as seven weeks.
Maybe it's seven months.
But we're looking at seven iteration.
As each of those iterations, or what some teams call sprint, rolls into view, the team does a different level of planning.
they do something called iteration planning.
Sprinter iteration planing, we break the product backlog items, those big index cards shown on the top of the slides, We break those down into individual tasks.
We estimate the tasks in hours.
Fairly straightforward process done by Agile and Scrum teams.
The next Sprint or iteration comes into view, and we do it again.
we'd break second set of product back log items into smaller tasks Now to talk about Agile planning, I kind of want to address what's a good plan.
Here's what I think is a Good Plan.
A Good plan is one in my mind that supports reliable decision making.
One where when we look back on the project, We say we made the right decisions.
We look back, and we say, we might have made a right decision.
That might be us saying, I'm glad we said June.
Here it is, the 6th of June, And we're releasing this thing.
And made it on schedule.
Or it might us looking back on a project and saying I am glad that we put three teams on this.
Look at the money piling up in the bank.
I I glad had three team instead of one do it.
Maybe a reliable decision is to look back on a project that we didn't do and say, I'm glad we did do that project.
I am glad last December we chose not to build this product.
Our competitors finally came out with theirs three months late.
Not getting good reviews.
We probably wouldn't have done it a whole lot better.
I'm glad we chose not to do that product.
The world's not ready for that project.
All right, we were ahead of the times.
Let's do not that.
So reliable decision making, when we look back on it, were happy we made the right decision.
Now, in order to be happy about a decision, We have to accurate.
So we might be sitting here today and say, we're going to release this in the third quarter.
Actually, that should say the fourth quarter, because that's not accurate.
We might look at this and we say we are going release it in fourth-quarter.
Later we narrow that down and it will be December.
Later we narrow it down and we say we're doing two week sprints.
It will not be the December 4th sprint, it will be December 18th.
So a plan needs to be accurate.
A plan does not need to precise.
The plan should only be as precise as we can support with the information we have at the time.
Now I'm using two words there we use all the time, accurate and precise.
Accurate and precision.
I think plans always need to be accurate.
It is almost criminal.
Yes, I am almost in favor of jail time for an inaccurate estimate.
But I do not want to push a team for unduly precise estimates.
Now, I'm using two words there, accurate and precise.
We use them all the time.
I always knew what they meant.
But I didn't have instant recall on accurate versus precise, and I thought about it for a long time, trying to figure out what do I mean.
And I asked people, people would give me these definitions that had to do with dart boards and clusters of darts that hit the board or didn' hit board
and things like this.
So I finally figured out how to think about accurate in precise Here's how I figured it out.
Here is my example.
This is just a true statement, don't worry about accurate or precise for a moment, just true a statement.
I have a daughter whose birthday is November 25th.
November, 25. Now suppose we're wrapping up 50 minutes from now and you say, hey Mike, you mentioned you have daughter, when's her birthday?
And I say it's in November.
Is that an accurate answer?
Yeah, it is accurate.
Her birthday's November the 25, I'd say its November it accurate, is it precise?
No, it's not very precise.
It's better than me saying, oh, thanks for asking.
Her birthday's in 2012. I mean, that's a horribly imprecise number.
That's helpful at all.
Now, me telling you her birthday is in November is not precise, but it is accurate, meaning it might be helpful.
Maybe you are my daughter's long-lost aunt or uncle.
I'm 1 fourth Norwegian, so maybe this is possible.
You are my aunt, my daughter's long lost aunt or uncle.
And so you put a birthday card in the mail to her in November.
She gets it in november and she thinks, ah.
My Norwegian aunt or uncle remembered me.
How great.
Trust me, this works.
I have two nephews born in May.
i have no idea when in may, just may.
All right?
I put $20 in the mail to them early May, they get it in, May they're both college students.
Beer money from your uncle shows up, you're happy.
They think I remember their birthday and I do, I remembered the month and that's good enough for an uncle.
Right?
i think.
Now, suppose instead we're wrapping up and you ask me when my daughter's birthday is.
Remember, it's November 25th.
And I say, thanks for asking.
It's January 3rd, 415 PM.
Is that accurate?
Is it precise?
Yeah, it's very precise.
It's precisely wrong.
So in order for an estimate to be helpful, and has to accurate, there's no weird scenario we can make up.
No long lost aunt or uncle scenario, we could make where me telling you January 3rd, 4.15 PM is helpful.
Not.
Wrong.
Can't be help.
Our plans, whatever we put together, have to the accurate.
I love this quote.
This is from John Maynard Keynes, famous British economist from the last century.
He said, it's better to be roughly right than precisely wrong.
He's also the British economist who said, government ending can end a recession.
So I don't know how much we should trust him.
But so a very famous British economists.
I love this quote.
Better to be roughly right than precisely wrong.
Sounded like a bumper sticker the first time I saw this.
This is actually a powerful statement.
Roughly right.
Hey, boss, I can't give you a precise plan, but I'll give one that's roughly, right?
Sounds like your boss is going to like that.
That actually might be helpful.
We have to accurate.
So that's our goal, put together accurate plans.
Now when we talk about Agile planning, we're going to use something called velocity.
Velocity is the amount of work that a team finishes or plans to finish within an iteration or sprint.
And I'm using those terms interchangeably here, iteration, or Sprint.
So if we run an Iteration, and at the end of that iteration we find we have finished three pieces of Work, And those pieces have Work were estimated at
four units, 10 units and one unit, We would add that up and say this team has a velocity of 15. The velocity of 15. Velocity,
to me, is always measured in the long-term units that we put on things.
This is going to be story points or ideal days.
So if you see those little cards up there, those are index cards.
Those represent our user stories or our product backlog items.
They're estimated in storypoints or idea days, we add that up, and we call that velocity.
There's a graph of a real team here.
The team's in Denver.
I've graphed them over the last nine sprints.
The main thing I want you to notice from this velocity graph, velocity bounces around.
Velocity is not stable from sprint to sprint.
It will change.
So this team here has an average of 33. But an interesting observation here, they've never had a 33, where it looks like they might have near the end there,
they had a 34 then a 32. They never actually had 33, but that's their average.
So velocity is useful over the long term.
I do not think it is appropriate for a team to say something like, our velocity's 33. We have one sprint left.
we will get 33 done next sprint.
No, no, what's useful is for them to have 10 sprints left, and an average of 33. We will average a 33, we'll probably get around 330 done in the next 10 sprints.
That's helpful, the long term.
Velocity is not useful in this short term, it's a long-term predictor.
Long-Term predictors.
Now we're going to use velocity in five different planning scenarios here.
Where to talk about it the basic simple case, a team where we have historical data.
It'll be kind of our base case.
Next we will talk how to do fixed date and then fixed scope plans.
There's a lot of people doing contract development.
How do I guarantee a particular scope?
We'll talk about how to predict a plan when we have no velocity data.
This may be your situation if you have a brand new team.
And then we'll talked about what to do with a team changing size.
If you have any questions along the way, just raise your hand and signal me.
We'll take their questions as we go.
Now what I'd like to do is to calculate our confidence interval around our historical averages.
I showed that velocity graph a moment ago and I said their average was 33. Well, that's too simplistic.
I don't want to use an average.
All right?
I want a look at a confidence interval.
Now, a confident interval is something like this.
As reading a report on climate change.
We used to call it global warming.
And now we got to called it climate changes.
So I was reading this report and climate changed.
It said that by the year 2100, the earth is going to warm 3.8 degrees.
Now think about that.
Think about.
We have trouble predicting three months into the future.
And here we've got scientists predicting down to the tenth of a point how much warmer we're going to be 90 years from now.
That's impressive.
It's very impressive Well, I read the article, and it got a little less impressive It said 3.8 is the average.
The actual confidence interval ranges from one and a half to seven degrees.
OK, that I buy.
Because it is pretty hard to predict that 90 years from now, we're going to be 3.8 degrees warmer.
That is really tough.
OK.
1. 8 to 7 degrees?
That I by.
You guys are hedging your bets.
Your scientists are hedge in your bet.
Now, imagine you were at the scientist convention where they ask these guys this.
If you're at this scientist's convention, and you want to do this survey, you wanna walk around and ask scientists, how much warmer is the Earth going be?
And you walk around, the first guy says 4.1 degrees.
Next guy, says 3.6. The next woman says, it's going to be 3,92 degrees, and you keep asking all these scientists.
Most of them are around that type of number.
You ask one guy and he says plus 43. Plus 43 degrees.
Yeah, yeah, plus 43. That's what my model shows.
Throw that guy's data out.
He's a nutcase.
Right?
He is an outlier.
All the other scientists are talking about 2 to 7 degrees, maybe an 8 degree here and there.
This guy has got plus-43 degrees?
Throw his data, out, nut case, outline data.
You keep asking people.
Ask another one.
Yes, the next one.
And he says, oh no, no.
No global warming.
Global cooling.
Negative 9 degrees of global cooling, our Martian overlords are going to land here and turn Earth into an ice factory for the rest of the universe.
In that case, throw the data away.
So what we do here to calculate a confidence interval, we look at the date that we have.
And we throw away the outwine observations.
The more people you ask, the more outwind observations you have, then more you get to throwaway.
If you asked a couple hundred scientists, you're going to through away more data than if you'd ask a dozen.
So here, real data, my confidence interval around this range of data is between 34 and 41. I think I've got nine observations up there.
When I have nine observation, I get to throw a one off the top, and I throw away one of the bottom.
So that's why I ignored those top and bottom observations.
Our confidence interval, we are 90% certain that true future velocity falls in the range 34 to 41. I know this from looking it up in this table.
I'm not going to go through the derivation of this.
This is based on binomial distributions and is a technique called a confidence interval around a median.
All right, this table tells us how many observations we can throw away.
If you've got 0 to 7, you don't get to throw anything.
Once you get eight, that's where things start to get interesting.
With eight or more observations, we throw away one.
Well, the 11 or 12 observations we through away two.
So the more observation, more outliers we threw away.
Now, you can memorize this table if you want, or we have this on our website.
We have a confidence calculator on a website, this presentation's on the website too, by the way, mountaingoatsoftware.com,
all the presentations up there.
Here's what we're going to do with these numbers.
Think about that 34 to 41 for a second.
Imagine we have five sprints left.
Somebody wants to know, where will you be five Sprints from now?
I multiply 5 times 34, my low number, and I count down 5 x 34 story points or ideal days.
And I tell my boss, we are at least going get to here.
We're at lease going go get 170. I can countdown 5x 41. Countdown 205 points.
Remember, five sprints left.
And I tell somebody, we might even get all the way down to here.
What we've done here is we created a confidence interval, and we use that to point arrows into our product backlog.
That is a prioritized list of features.
I can now go to somebody and say we're going to get at least here, might get to hear.
Now what's interesting about this is not only did I point those arrows in the backlog, I could put percentages on those areas.
We are 90% likely to be in that middle range.
5% chance things are worse than the top arrow.
5%, chance, things, are better than bottom arrow, but 90% likely to end there in the middle.
This is powerful.
I can now go to my boss and say, I am 90%, sure, we finished between this and that amount.
We're going to have to deal with the issue.
And I know we can't go all bosses.
You go some bosses and you say I'm 90 percent certain we finish between 170 and 205. A lot of our bosses will say great,
Still, behind the scenes, at the quiet of your desk, I want you to do the right math to know what the range is, to what know the answer is.
You got a boss like that, OK, we're going to have to change it into a point estimate.
He can't go to the boss with the truth.
Your boss can handle the true, the 170 to 205. We're gonna have change into point estimates.
But I still want us to be the write math.
So this is our simple case.
This is a straightforward one where we have a team with some data.
Overview, you're assuming that the estimates are accurate as you go down the backlog?
Yes.
So the question is, am I assuming the estimates are accurate as I go down the backlog?
Yes, I am assuming that the estimate are accurately as we go the back log.
To have an accurate plan, which is our goal, it takes effort.
It's going to take effort, and I advise putting the effort in only to the point that it will change decisions we make.
If knowing exactly where we're going be here is worth it, you should put in that effort.
If knowing where we're going to be here is not worth the effort, don't put it in.
I'll give you an example.
Inside of Mountain Goat, we are doing a contract development project for somebody right now.
We've guaranteed delivery of certain amount of features by a certain date.
Were doing all this on there.
I love this stuff.
We didn't do any of this on that, right?
I'm doing a little bit of the programming, not much of it.
I am enough of a programmer to know about how long the things are going to take.
So if you have an environment where things like heads will roll if give a wrong estimate, a long prediction, you're going to have to invest more into getting
those backlog items estimated.
You're gonna have do it fairly accurately.
This is what I was mentioning earlier.
We have a calculator on our website you can use.
It's all free.
we don't sell this type of stuff.
Just go on there, and you type in your velocities.
They'll tell you what your range is.
This slide also goes into the derivation of the math that we want to do on a middle of an afternoon.
Let's talk about fixed date plans.
Again, I know some of us will be in this kind of contract environment where we have to promise a set of functionality by a given date.
So here's what we're going to do with a fixed-date plan.
With a fix date plan, there are three steps.
The first step is count how many iterations or sprints you have.
Look at a calendar.
Just circle every second week or third week, fourth week.
Whatever your sprint length is.
Count how iterations you got.
This part's easy.
Second step, estimate your velocity as a range.
We just talked about how to do that.
Throw away the outline observations.
What's left is your lossy range, then what you do is you take that number of iterations times your last year range The low number of iterations times the
velocity range.
Or the low velocity times number sprints, the high velocity time the number sprint.
That'll give us our plans.
Very similar to what we just did.
Let's see this as a picture.
So we're gonna look at a calendar.
We're going to count our iterations.
In this case we are doing two week iterations, so I just look the calendar, I count it, and I say we got room for six iterations here.
we look in our historical velocity data here, Here's from a team I worked with that let me use their data.
Here are their observations.
They've got eight sprints.
With eight Sprints, we get into that part where it's interesting.
I can throw away the best and the worst.
So they're the Best and The Worst.
And we look at that.
And from there, we can decide what our velocity range is.
We've got a 25 to a 30 in this case.
That's our philosophy range.
Now, in determining what we commit to, We got our stacked up product backlog.
I multiply the 6 times the 25. There's my will have section.
Multiply the six times 30. that separates my backlog into a might have and a won't have.
Now I said earlier, sometimes we have a boss who can't handle a range.
I can go to my boss and say, you'll get 150 to 200. Or it is 150 180 here.
Some bosses can handle that.
So I'm going to have to turn this into a point estimate.
Here's how we can think about this.
If you promise your boss, client, or customer this top amount, Your boss, client, or customer, if it's a client they will not sign the contract.
They're going to say, that's all I get?
In six sprints that all you're gonna give me?
Your bosses gonna be frustrated too.
Your Boss will be very disappointed.
Six sprint, I'll get that.
That's it?
That is pitiful.
I may have to have another team do this.
But if my boss or client goes for it, i'm set.
This is not going be hard.
So if I can talk them into this, then I'm good.
On the other hand, maybe I want to promise down to here.
If I promise down here at the bottom, my client signs on the dotted line today.
My boss loves me.
my boss gives me a big kiss on my lips.
Maybe a good reason not to promise this amount.
If I promise this amount, though, I'd better be careful.
This is the fastest we can possibly go.
If my client says, go for it, sign the contract.
I've got to be carefully.
this is optimistic.
So think about what we're doing here.
We're taking on different types of risk, right?
The top one, I'm taking a lot of short-term risk.
If I promise that top on, people are not happy with me today.
That's all I get.
Mike, that's it.
But they're going to be happy six sprints from now because I might over deliver.
I promised the bottom one.
Oh, fantastic.
But they're going to be a little disappointed six months from now, because I may not deliver all that.
Six sprints from may I not delivery all of that?
So what we're trying to do here is balance risk.
And we are looking at risk now.
All of contract development, this is what Mountain Goats done for years when it started doing contract, development.
My company, Mountain goat software, is contract is all about balancing risk, and in this case, the type of risk we trying balance is I'm going call expectation
risk and delivery risk Right?
Expectation risk.
Expectations risk is the risk of not meeting someone's expectations, right?
They're disappointed in me today.
Delivery risk, is a longer term risk not delivering everything I promised.
So let's look at these two possible points that we had up there.
If I promise just the will haves, that'd be that top arrow, not the bottom arrow.
The top arrows on what we just looked at.
I'm taking a lot of expectation risk.
We're high up on the vertical.
People are not happy.
I am not meeting their expectations today.
But delivery risk, not so much.
Right?
I Am going to be able to deliver this.
This will not be hard.
If instead I promise the bottom arrow, If I promise all the might-haves, I'm taking on a lot of delivery risk.
I may not deliver all that.
But very little expectation risk, people are happy with me today.
And meeting their expectations when I walk into that meeting and say, here's what we'll deliver you.
Yeah?
If you constantly give a low estimate and deliver more, won't that give in the long term, your boss will always expect you to deliver them more than you promised.
So when you deliver just what you promise, he is disappointed.
I think you're right.
If we always under-promise and over-deliver, the boss comes to expect us to over deliver.
And so we're always having to play that mental adjustment game.
So I'm not necessarily proposing here that you go to either one.
I am looking at the two extremes, and my recommendation is going to be that in most cases, you have to go somewhere in between there.
What I'd really like to do is go to my boss client or customer and say, I will deliver you between here and here.
I've got six sprints.
That's fixed.
In six prints, i'll deliver between 150 and 180 points.
that's the relationship I would like have with my Boss client customer.
But I understand that bosses, clients, and customers don't necessarily trust us.
If we tell them the 150 to 180, they think we're only going to give them 150. So they get mad and they push for the 180 hoping to get 170. So my recommendation
is we have to understand that relationship.
We have balance the amount of risk.
I do not want to always under-promise and over-deliver, just like I don't want over promise and then not make it either.
So to me it's a matter of looking at this and balancing the type of risks that I'm taking on based on where my boss, clients,
or customers' expectations are at that time.
So the question you're asking, basically what's going to happen there is the boss's expectations are going keep going higher.
So it'll be harder to over-deliver.
Let's look at the opposite one here, which is a fixed scope plan.
Same thing, same process.
We start out, we add up the product backlog items.
We estimate our velocity as a range, and then we use the sum of the product backlog divided by the velocity range.
So last time we multiplied, this time, we're going to divide.
OK?
So let's see an example here.
We take our product back log.
we add it up.
We add up all those product backgrounds, those user stories, we get 120 story points.
We look at our past velocity.
we estimate that as a range.
In this case, 15 to 20. And then we are going to divide.
All right?
We take the 120 store points, divide it by 20, We get it could be done in six iterations or sprints.
We divide it by 15, we get that it can be eight iterations, or sprint.
And we say that this project could take from six to eight.
So this is the same approach we were just looking at.
In this case, though, were dealing with a fixed scope.
I have 120 points.
They have to deliver all of this.
When can I get?
Well, you're going to get in 6 to 8 sprint.
Now, same thing, I'd love to go to my boss and say it'll be 6 to 8, but not all bosses can handle a range.
So let's see how we can turn this into a point estimate that we go back to our boss with.
If we promise just the short estimate, boss, you'll get it in six sprints.
Your boss is going to love you today.
Your client is gonna sign the contract right then.
They're not even gonna get competitive bids, they're happy.
But be careful, this is the fastest you can possibly do it, you may not make it.
Delivery risk from before.
If we promise the bottom one, the eight sprints, Probably won't win the contract.
Your boss will probably not be happy today.
But if they are happy enough to let you do the project, they'll be Happy later.
Because in eight sprints, you'll Be done.
You'll deliver everything.
Maybe they only take seven sprint.s You will be able to meet this one.
So again, what we're looking at here is a balance between the short-term expectation risk, how does somebody feel today when I tell them that estimate,
and the longer- term delivery risk.
Will I be able to deliver what I promised?
And contract development is about balancing those two things out, expectation and delivery risks.
The thing I want to point out with both of these examples, we'll move on to another one, is the use of a range.
Notice in both of these cases, we used a Range.
In the example of fixed date project, I have to have this six sprints from now.
We used the Scope Range, OK, six prints from no problem.
Well, lock that in.
Will guarantee you six Sprints.
But to make that happen, We're going to promise between this and this much functionality.
In the other case, in a fixed scope project, I need this 120 points, we used a date range.
OK, well, lock down the scope for you.
That's fine.
But we use a data range to do it.
We will give you this much, between this and this number of sprints to finish that scope.
So in both cases, will use our range, little bit coming back to the idea here of accurate versus precise.
One of the best ways to be accurate is be a little less precise, I'll give you all of that, but it'll take six to eight sprints.
So we back up on some of the precision, we get more accuracy.
And again, the plan has to be accurate to helpful.
I want to do a little exercise here.
Need to pass out a handout here, so I get that started here in a second.
Here's the exercise I'd like you guys to know.
Let me ask you to just kind of form up into some little groups around where you're sitting.
Our company is getting ready for a big trade show.
We're getting right for NDC, let's say.
We make tools for managing ADSLE projects.
We finished version one of the project, and now we're getting ready for version two of their project.
The boss wants to know what features we can guarantee will be in there for iterations from now.
What can we guarantee we'll be there in four iterations?
So which features can be guarantee and which feature do we consider likely?
All right, here is the data I want to share with you.
Here is your past historical velocity.
So these are your velocities.
We've got 10 sprints there.
You may not remember it, but I'll point it out from the earlier slide.
If you have 10 Sprints, you get to throw away one off the top, one of the bottom in determining your range.
That was the early point we had.
I wanted you to think about what that's going to be.
And then here your product backlog.
This is prioritized.
So basically what I'm asking here is, based on the previous slide, how far into this backlog are you going to penetrate?
So while you're talking about that, I'll back up to this one to let you get started with for doing some of the math on there.
While you do that I will pass around the exercise on a handout here so you can talk about this.
Okay, let's talk about this for a few minutes.
We'll go into our two other situations here.
So the two questions here were how much can we guarantee?
I know nothing's ever a guarantee, but you know what I mean.
How much we can guarantee to the boss in four sprints?
And how many do we think is likely?
How many you think we could guarantee.
What would you give the bosses essentially a guaranteed here?
What do you thing?
First three items, right?
So let's see if we do this.
So if you did this, we'd throw away two sprints.
We'd threw away the best and the worst.
I can't see them because I got these speakers here.
What does that give us as our velocity range?
Somebody did the?
14 to 25, okay?
So if we got 14-25, we can look at the 14, multiply that by four sprints, all right, it's gonna give us 56 points, right?
I'd look this then and I count down 56 or so.
I think I made this a little bit easy, the first three is 53, well we could certainly do that, I mean 56, that's really only our 5% chance of being worse
than that.
And look at it this way, too.
You've got a 5% chance of being worse than that.
That's the math.
The math says 5%, chance being worst.
But think about it.
If you've a team that's hitting their minimum, sprint after sprint, they're probably going to kick it up a notch somehow.
They're going find a way to get a little bit better than minimum.
So probably not even a five percent chance.
I might look that and say, OK, we can get those first three.
Maybe there's another small one I can.
Or maybe we could split the fourth item into two parts.
We'll promise the boss the first 3 plus part of the 4th.
What about the realistic?
What was the question exactly I had here?
How much do we think is likely?
Now, to get the likely answer, I wouldn't take my high velocity and multiply that by 4, because that's not necessarily likely.
That's our maximum.
So the likelihood number on here is perhaps in the middle.
The likelihood in here where I have to use judgment.
We're talking a lot about math.
Here's my biggest thing with all this math.
Don't ever become a slave to the math, OK?
The math here is a tool, right?
Our brains are smarter than the map.
Use the Math to help you make decisions.
So I look at this.
I say, here's minimum.
Here is my maximum.
And I've got to give the boss the most likely number.
Oh, I think it's here.
The team's doing pretty well lately.
No big holidays come in.
Let's go down a tiny bit more.
All right, my team's really struggling.
That new database guy is just not getting along with people.
Let me back it up a little bit.
So use your judgment.
Never become a slave to the math.
OK?
Let's talk about two other.
two other planning scenarios here.
The first one is a team that has no velocity data.
And this is real common situation.
You're brand new, right?
Or you've been doing Agile for a long time, you just don't have an existing team, got a brand-new team.
So how can we predict when we don�t have a Let's assume we have the team.
They've never worked together, but we had them.
So get the teams together and have them plan a sprint.
Have them go through the process of planning a spring.
The way I recommend teams plan the sprint is this.
they look at their product backlog, they take the top item off the product back log, They break it into tasks and hours.
What do we have to do?
We've got to code this, design this.
Oh yeah, we've gotta automate this." They come up with a list of tasks.
They estimate those tasks, and then they say, can we do this user story, this backlog item?
Yes we can.
We can commit to this and they grab a second product backlog.
Then they break it into tasks and hours and ask themselves, Can we commit this one?
Yeah, We Can Do This One.
And they keep going until they're full.
Soon as they're full, they stop.
As soon as their full we can look at the product backlog items they selected and say, how many points does that add up to?
This process is called commitment-driven iteration planning or commitment driven sprint planning.
During commitment during planning, we don't use story points.
We don' use velocity.
But at end of the meeting, because we have storypoints on our user stories or product back items, We can add them up.
Let me show you an example.
This is a real team.
I like this team because they're fairly interchangeable.
Everybody on here could do everything, which makes the example easy.
You don't have to worry about who was the tester and who is the programmer.
These three are fairly interchangable, so we started out, I asked them, do your personal math.
And Sergey said, oh, I'm available about four to six hours a day.
10-day sprint, he's got 40 to 60 hours.
Yuri said the same thing.
Karina said I am available at about the rate, but I only have time on this project.
So she was 20 to 30 hours We added up, we've got 110 to 150 hours available to this team in iteration.
We start to plan a sprint.
we grab the first product backlog item, We break it into tasks and hours, All right, shown on the right there.
We add that up, it's 31 hours.
Can we ask the team if they can commit?
Well, of course we can.
So we grab a second one.
we break it into task and hours, ask a team of they commit to it.
Yeah, yeah, course, we could.
Only up to 79 hours now, 77 hours So we grab a third one, we break it into tasks and hours.
We ask the team if they can commit to this.
They're now up to 125 hours, right in the middle there of that 100 to 150 hours and they think about it.
Yeah, yeah, you know we're good.
So if they can commit to it, they grab one more backlog item.
They grab on more product backlog items, 22 hours.
Now we're up to 147. The math works.
It fits in the 100 to 150 range.
But they said, oh, no, that's filling the sprint too full.
We can't commit those four stories.
Notice they didn't talk about story points, they don't know velocity.
They have storypoints though.
So at the end of that meeting we can look at three stories we've committed to and we take a guess, a forecast of their velocity Everybody see what it would be?
We'd add up those first three user stories, those back log items, and say we've got a three point story, a five point, another five story.
Our estimate of velocity is 13. So this team, I call this backing into velocity.
This team would back into a prediction of a 13 point velocity, Now remember something I said earlier in this session, I've said the importance of a range,
right?
Use a arrange.
So what I don't wanna do is take that 13 and trust it, because I do not trust.
I wanna turn it into a rage.
Here's what you can do.
If you don' have any historical data, just take a guess.
Take that thirteen and take guess, remember don''t become a slave to the math.
Let's say the team did that planning meeting in 45 minutes.
If you've done any agile, you know that's a very quick planning meeting.
That team did not take that very seriously.
And they came up with a velocity of 13. I might look at that and go, that their high number.
Look at their velocity, I'm going to say maybe 9 to 13, or 9 or 12. They did that so quick.
If they had taken longer, they would have seen more tasks, committed to less, 9-12.
All right, so don't be a slave to the math.
At 13, you use it to inform your decision, but it doesn't have to be your decisions.
So if you've got no historical data, use your intuition.
If you have some historical from other teams, This is a new team in your company, but you've got plenty of other agile teams.
What you can do is you're going to look at those other Agile teams and use their ranges.
Let's say all of your other teams in the company average a plus or minus 20% on their velocity.
Velocity is in a to a minus or plus 20 percent range.
It'd be a total range of 40%. I could look at that and say, well, for this team, I bet the range is going to be the same thing.
No reason to assume this is team is gonna have any different of a relative range than my other agile teams.
So I might look this and go, wow, this has a plus or minus range around here.
And I think they did this really well.
Let me take that 13 and make it 20% bigger, 20 percent lower.
So we can look at our other teams and use what's called their relative standard deviation, just standard deviations as a percentage.
Let me show you an example.
Here's one team.
This is real data.
All this stuff's been real.
So we get this team here, and I could look at this.
And from that, I can calculate their average and their standard deviation.
Their average, their means, 22. There standard is 3.8. Just use Excel to do that.
Relative standard deviations is standard aviation turned into a percentage.
In this teams, 3,8 divided by 22, 17%. That's one team.
Let's look all the other teams inside of our company.
So let's see, did I do it for all the other teams?
No, I'm just going to do for this one team here.
What we want to is we're going take that and we'll average across a bunch of other team in our company.
When I've done this, on a couple hundred teams, my data is about 19%. I find that the velocity bounces around in about a plus or minus 19% range.
So that's the number I use.
I'd want you to find it out for your own company, but in general, what I found industry-wide is 19%, so let say we've got a team who has estimated their
velocity to be 11. I'm going to take that, I am going increase it by 19%, the average number I found.
I will lower it 19%. That's going take our 11 and turn it into a range of 9 to 13. And I still trying to give the boss a prediction,
when are we going be done.
So I take the total number of story points on our project, or I multiply this by the number sprints we are doing.
And I'll separate my backlog just like before into a will have, might have and won't have section.
So this is an example of being able to predict velocity when we have a brand new team.
Now, I started out with a very simplifying assumption.
I said, you have the team, let's pretend you don't even have that team?
I had to do this in situations where we were doing contract development, we didn't have team together, and if somebody signed a contract we'd put a team
but we don t have it yet.
So what we would do is we get together Two programmers, a really senior programmer, senior tester, mid-level tester a good DBA,
and a UI designer.
Whatever we thought was a representative team for that project.
And I would ask that representative set of people pretend to be the team.
Plan this sprint.
All right?
And then I had a prediction of velocity for a representative team.
And I looked at that and said, well, if we're going to hire a better team, or we put slightly better people on here, I can raise the velocity a little bit.
If I think we have a worse of a team I could lower it a bit, right.
So I'm going use the math to inform my decision.
It's just going help me make a decision, it's not going give me the exact answer.
OK?
So you can actually use other people in the company to approximate the team if you don't even have the time yet.
A couple esoteric situations here, right?
A lot of us are gonna be in this situation, but some of you might.
Let's look at one more situation.
This is a situation where velocity, where team size is changing.
You've got a six person team, maybe you're gonna go to eight people, and you try to predict what's gonna happen to my team when we go eight to people.
So what can we do to make predictions in that situation?
Here's what you can do.
Build up a spreadsheet that looks like this.
What this spreadsheet is showing me is the team's initial size and then the size it changed to.
So the top row there is a team that went from six to seven people.
And then what I track is what happens to their velocity in the first, second, and third sprints.
compared to the average of their preceding five.
I found that averaging out the preceded five sprints was good enough.
And I would take what happened in the next one sprint.
So let's just take that first cell there where it says negative 20%. It says six, seven, and then negative twenty.
This is a team that went from six people to seven people.
Velocity went down 20 percent.
Why would velocity go down when the team size went up?
Had to teach the new guy?
Yeah, overhead of getting that new person up to speed.
Got to show them where the source code is, how to check stuff in, got to give them a walk through of where their main modules are,
things like that.
So in the first sprint for that team, velocity was down.
Second sprint, velocities still down, negligible 4%. In the third sprint though, we found velocity is up 12%. I tracked this longer.
I track four, five, six sprints.
What I found is two things.
One, things stabilized after three sprint.
So it wasn't worth it tracking longer, and two, teams changed again.
It took six to seven people, then I took them to eight, or I take them back to six.
Right?
So the team didn't stay the same size.
so I only track this these days up to three Sprints I find that good enough.
Tracking longer not worth the cost.
The second row is showing a different team that went from six to seven people.
Now that column that says sprint or iteration plus one, that's not saying January of 2010 or anything like that.
Those two data points could have been a year apart, could've been five years apart.
Right?
It's just some team, the one from 6 to 7 people in its first three sprints.
Another team the went form 6-7 people, year away.
What happened to its velocity?
Another team went from seven to five, another team from eight to six, seven, eight.
If you have a lot of teams, when I was doing this, the first time I did this we had about 25 teams.
Teams were constantly changing size.
We'd move a person here to there, things like that.
Somebody would join the company.
So this type of spreadsheet can build up very quickly if you've got a medium to large department or organization.
This will build very up quickly.
You track this across your entire organization Now suppose somebody comes to you and says, Ugh, that's not enough.
I need more than that by the end of the year.
How much more could you give me if I gave you one more person?
Right, you've got a six person team today, how much could more you get if you had a seven person on the team?
Here's how we'd look at that.
We would take out all the rows that are six to seven on this spreadsheet.
All right, I'm going to look at those six to seven rows, and I am going average the impact of their velocity.
In that first sprint, it's negative 20 and 0. One team stayed the same, right?
So I would say they had an average impact, of negative 10%. That's going be this bottom table.
All Right, in the second sprint we have an Average Impact of Negative 5. By the third sprint were a plus 13. I had to do this in two very common situations.
1, i had a boss who came me and said, I believe you, I can't get all of this next year.
How many more people would it take for me to get everything I want next here?
And I went back and I added a certain number of people to our company.
And so, okay, if we had 18 more, we could do everything.
I had another boss, different company, came to me and said, 10% layoff.
And I went through and I had a list of employees, and just kind of X'd out every tenth employee, right?
I wasn't really firing them.
I was just, okay, that team loses a person, I took off every 10th person.
Adjusted their velocities, did the math on it, went back to my boss and said if we lost 10%, we would have lost a project last year about the size of,
in that case it was a product called utilization management.
We would've lost the utilization project, could you have lived without that project?
Wow, that's a little big.
Why don't we do a 5% layoff?
I didn't go redo the math, and he didn' need me to do that.
But we decided to go about half of that size lay off in that company, where we let 5 percent of the people go.
So we save 5 % of jobs by actually having some data on this type of thing.
One of the rules I had when I was doing this as a VP in these companies that I'm talking about, I have a rule that no team could spend more than one minute
per sprint collecting metrics.
It may look like we're collecting a fair amount of stuff here, but we had it one-minute per sprint.
We had an email address.
Every scrum master would send an e-mail to that address once per Sprint, the first line listed the number of team members,
second line list of velocity, things like that.
Real simple e mail.
Demon running watching the email address parsing stuff pointing it into a mysql database so our Scrum Masters will spend one minute per sprint Sending
data that was all we did all right, but it gave us the power to do a lot of these type of things OK.
Taking you right up to the end.
We've got a couple minutes left, but I know you're probably anxious to get to next section.
I'm not going anywhere, so I can hang around and take some one-on-one questions for anybody that has them.
So if you've gotten any questions on this stuff, hang round.
Be happy to talk about it further.
And back every couple months.
If you have been here, you heard me say this.
Here's my contact information.
Love talking about this type of stuff.
Feel free to email me anytime.
Thank you, guys.