- [Narrator] First of all, let's establish the context.
What is PI planning?
Why do we do it?
What's the purpose?
What's the point?
This is what we call the pacemaker
of the agile enterprise.
We talked about cadence and synchronization at length.
This is the cadence and synchronization point
for every agile release training.
They may be different (mumbles).
More typically they are going to be aligned
as we get into large solutions.
We're going to see that's as important
as aligning this (murmurs).
But this is the seminal event.
If you're not doing face-to-face PI Planning
or face-to-face-to-face PI Planning,
you're not doing SAFE
and you won't get the benefits of SAFE.
What is it?
A couple days every eight to 12 weeks.
10 weeks typical.
You pick the cycle.
If you look at the big picture, it shows 10.
We actually run 12 in our shop aligned
with our quarterly boundaries.
We have a very small shop.
In very large shops,
where they also want to align with quarterly boundaries
or it may be that that's too slow a learning pace.
You may be innovating in a brand new area
and you need feedback quicker than that.
So, as I mentioned earlier, you might see six week PIs,
eight week PIs, 10 week PIs, or often typical 12 week PIs.
We're gonna try to get everyone together.
There's right back (mumbles) manifesto.
There's no substitute for face-to-face planning.
We'll talk a little bit about the practicalities
of that, et cetera, in a little bit.
But we're gonna try to get everybody
as present as possible in person
or at least online in real-time at the same time.
Product Management they have their important role.
They're gonna own the feature priorities.
The development teams own the story-planning
and high-level estimates and they own the plan.
Architects and engineers and UX people
work at intermediaries for governance,
interfaces, and dependencies.
Now this is, in some ways, easier to experience
or see than it is to lecture through.
So why don't you take a minute here,
there's a very short PI Planning video.
It runs about a minute 48
and this gives you a sense of the experience.
So go ahead and watch that now,
so you'll know a little better what I'm talking about.
So, I expect that video gave you a sense
of the animated purpose of people getting together to plan
and what it's like to have the business owners,
the product managers, product owners,
and teams together planning.
You notice they plan three weeks sprints.
People plan three weeks in sprints.
Our general recommendation is two weeks.
Why because you get faster feedback
but people work with different sprint lengths
in the context of SAFE all the time.
We definitely prefer two.
But you saw how the process of becoming agile
was a process of constantly communicating objectives.
Finding out what the business wants.
Integrate that with what the developers can do.
Have that little bit of debate.
Have that little bit of creative friction.
What about this?
What about that?
How could we do this differently?
That's the value.
I'm fond of saying that there's no magic in SAFE.
It's really principles in blocking and tackling.
But if there is magic, it's getting your 50 to 100 people,
the people who are personally responsible
for building and deploying and supporting
the system together to figure out how to do that.
It's a pretty cool thing.
If you haven't attended one, try to find one.
They happen all around the world.
I'm sure they're happening everyday.
So find one.
Attend it.
Get a feel for yourself of what this event is like.
The best I can do is kind of lecture through it.
So I'm gonna take you though the process now
and show you what the steps are that they would be following
in an event like that.
So what is the process?
The process is to take the input
and how do we reflect that?
We reflect that input as vision and program backlog.
Could be various forms for that
but generally what are the features we
are trying to deliver in this next interval.
We don't know that we can do it, necessarily.
They may have been sized
but certainly not broken out in user stories.
We don't know what teams might be available.
We don't know their context is.
We don't know how much backlog they have from other things.
We don't know for sure what kind
of maintenance issues they have.
We don't know for sure what their overall context is
but you know these are the most important features.
We're gonna go through a process
of the sausage-making analogy.
We're gonna bust all that up
and talk about it
and say is that really what you mean?
Will these stories accomplish that?
And how would that look when it worked?
And how would we demo that?
How would we know that we're good to go?
The outcome of that is gonna be
a few things we'll talk about.
A set of objectives.
Each team knows what they need to do.
Those aggregate in the overall PI objectives.
And then this funny looking program board
which we're mostly gonna use
to first identify and then help manage
dependencies as we proceed forward.
So that's the overall process.
Input.
Plan plan plan.
Output and commit.
However, before that, we have a chance
to establish a cadence.
So we talked about cadence and synchronization at length.
And, with this model we're gonna set this cadence
maybe even a year in advance.
I, for example, right now know
exactly all the PI plannings through 2018.
And that means that as I'm planning personal events
and vacations and things that I can do optional
and other work events,
I'm gonna plan around those.
So my commitment to the enterprise
is that unless something
unless there's
illness or something else that interferes,
I'm gonna be there because that's number one
on my priority is to participate as a business owner
and helping with the PI planning
and providing my input.
So you can set up the program calendar.
You can also set up the team level calendar
because you know when you're new system demos.
Two weeks from this day,
we're gonna have our first system demo.
We do our system demo every other week in our organization.
Too much overhead for us on one week.
Things don't change that quickly.
That's built into the calendar.
So, all of a sudden, my calendar is known.
A bunch of things that I was gonna have to react to
are now proactive.
I know how to participate in those things
and I know when.
I know when the next system demo is
and I know who my scrum master is
so I know how we're gonna get prepared for that.
All that is known.
Now we have our brains and bodies to do the work
which is what gets demonstrated
and build the content that gets demonstrated
rather than are we demonstrating and when.
Very important to have that cadence.
For a number of years, we had an agenda that evolved.
Every time we delivered it, it evolved a little bit
but it's really settled out.
And what I'd recommend is that you try it
before you modify it because it's been proven to work.
I'll take you through it briefly.
Just talk about the various elements.
The time boxes, fairly critical and yet some flexibility.
Somebody's gonna set the business context.
That's gonna be the highest person in the organization
that you can find that represents the highest level
authority and vision about strategy.
Product managers and potential product owners
are gonna kick in and give their talk
about the product and solution vision.
What we're trying to build.
We're not gonna forget about architecture
and we're not gonna forget about our technical practices
cause we have to involve them, as well.
Planning context, we'll talk about that.
How are we gonna do the planning?
The team breakouts.
Planning those sprints.
Feedback the plan draft review.
And then this all important management review
and problem solving.
We'll go through all of that.
That's day one.
Day two we'll come back and we'll have planning adjustments.
We'll start off by folks saying
we met last night and some things we need to change.
I have never, ever been to one of these sessions
after X years, including our own,
where there weren't changes to plan based
upon the fact pattern.
It's never exactly like you think it's gonna work out.
So you may go in thinking some things are gonna happen.
You're gonna go out discovering
that wow that couldn't happen
because of that particular situation.
Then we're gonna plan again.
Do the second breakaround.
Get ready for the final plan review.
We're gonna view the plans.
Come back and talk about risks and see how to adjust that.
We're gonna figure out if we're ready to go or not.
This person, one finger, definitely not on board
with these plans.
This person is very optimistic, maybe overly enthusiastic.
This person is going, I think we can do this.
Okay we'll talk about how that works.
And then we'll rework the plans if necessary.
If we get a lot of single votes
or if some issues gets addressed,
we'll stay and work on that.
So, consequently, you may wanna even...
Oh maybe, on a rare occasion,
that might roll over into another day.
Often planning happens Wednesday, Thursday
with days ahead of that for some other work
that we'll talk about in the IP iteration.
And then, planning retrospective and moving forward.
So that's the rough overview.
Two days.
Sometimes as long as two and a half.
If you're distributed over multiple time zones.
You're a large organization.
Sometimes as short as a day and a half
but I think the most important thing
the evening in between.
That's when you reflect and adapt and adjust.
Integrate the learnings and have a chance
to really communicate the changes
that would make a viable set-up plan.