Transcripts
1. Intro: Scaled Agile Program Increment Planning Overview: Hi and welcome to sprint
zeros safe program increment planning video
series on, on its side. And I want to invite you to an exclusive video
series where we are going to be tackling the challenge of how
to run an organized, effective, productive, and yes, even fun program increment
planning session. Now for short, we'll refer to it as the PI planning event. This is the main planning event for an Agile Release train of between 5025 people. Now that's a large event with lots of moving parts complexity, and lots of things
that can go wrong. Now the challenge with
such events is that a small mistake can impact
a large number of people, a large number of teams. And now that makes for potentially very
expensive mistakes. Sometimes running into thousands or even tens of
thousands of pounds. Over the past five years, I have run over 20
PI planning sessions and I have made many mistakes. I've even had a PI
planning Mutiny on my hands during one of my
many PI planning events. And I would like to save you.
2. Session 1 : PI Planning Challenges: Hi and welcome to Sprint Zero safe PI planning
series of videos. In this three-part series, I will walk you through
what is needed to implement PI planning effectively
in your organization. Let's discuss what challenges you would expect when running PI planning in your, in
your environment. So first off, let's discuss
what is PR planning in. Say if you have something known as an Agile Release train, now this is a collection of
between 512 Agile teams. They have a timebox called
a program increment, which is between eight
to 12 weeks long. The default is ten weeks, though most of the
companies that I've worked for typically use a 12 week iteration length to align with the
financial quarters. So what's the purpose
of PI planning? So PI planning is the
main planning event for the whole agile
release train. For all of the teams on the train for the upcoming
timebox or programming. So we run this at the
beginning of the PI. We use this event so that we can plan for all of the teams
on the Agile Release train. Now, remember, we may have up to a 125 people at a single event. So that's up to 12 P at 12 teams in theory
and in practice, sometimes even
more, I personally run trains up to 16 teams. So that's quite a
lot of complexity, quite a lot of things that can
actually go wrong as well. So to make sure that we
organize this event properly, we need to make sure that we put some preparation and
planning into yes, the planning of n. So
let's start by looking at what are the outputs
for the PI planning of it. So the first output
is the PI objectives. So the question is, what are the overall
objectives of this PI? What's the vision that
this organization is trying to actually achieve? What is the vision for the Agile Release train
and for this next timebox, what are the objectives that we want not a single
team to deliver, but the whole agile
release train. And obviously we want
to make sure that the objectives that we
have for this PI IN sync with the overall vision for the Agile
Release trained over a longer horizon
and for the vision of the overall
organization as well. So the next thing
that we want to have as an output is
the a dependence, what we call a dependency map. We really want to understand
any cross team dependencies. Now, the reason for
that is because the value may not always
constrained to a single team. Now value may span
multiple teams. And so we need a mechanism
to identify, visualize, and hopefully in time reduce those dependencies
by making sure we have got a optimally
structured teams. And so one of the key, key elements and key benefits
of a PI planning event is identification of these
cross team dependencies. Now, the next thing that we would want as an output
is an emergent roadmap. So each team will
have a higher level emergent roadmap of the
upcoming program increments. Now, depending upon the size
of the program increment, a team may have between 46
iterations within a PI. Now the law situation, if you look at the big picture, you will see over there
the loss iteration has an IEP acronym over there that stands for
innovation and planning. And that is the law situation. We keep, we keep that, we keep that free. Now this means that you will have to create a
team roadmap for between 35 iterations depending upon the size of your
program increment. Now, when I say emergent, the question is, what
do I mean by merging? So what we mean is that at
the beginning of the P II, there is more detail over there. We will know more about
each of the iterations. But as we go through the
iterations, There's this. We know less and less
information about that. And so we want to make
sure that we have more information upfront at the beginning parts of
the PI, less at the end. And we can do this by
loading each iteration with few stories and having
more granular stories. In early, earliest sprints. And in lattice sprints, we have larger stories that
may be split at a later date. So finally, oh, it looks like we've dropped off the impediments
and the risks already. So the finally, we want
the impediments and the risks to be identified for the Agile
Release strain as well. So all of the teams are gonna, are going to identify
what impediments they have at the program level. These could be things that like They could be
anything. It could be like resource issues
that they may have may have problems
with the with the with the architectural runway. They could have anything that
sits at the program level. It could be released,
challenges or anything of that sort. Now, of course, the
teams are gonna be responsible for their
own team levels, team level impediments. But the kind of impediments
that we're gonna be raising here are those that needs to be resolved at a program level. Now, we also have
risks there that may issues that may not have
actually materialized but could, could materialize
over the course of the current PI that need
consideration as well. Okay, so that's now
the outputs that we're expecting from the program
increment planning session. Now what I want to
discuss with you are what are the challenges
that you should expect or one should
expect when running a PI planning event in your organization
for the first time. Or even if you're,
if you've been doing this for a number
of times before. Now as I mentioned,
the PR planning event is a large event. It's a co-located event, ideally where we have
all of the teams coming into one location face-to-face, where we can have all
that rich interaction across all of the key players within the program increments. So you would be
expecting to have a good representation at
the team level and also a good representation at the program team as well as
key stakeholders as well. So as you can imagine, you're going to need space for all of these teams over that. So we're going to want to have ideally a table or an area
for each team where they can, where they can do that, where
they can do their planning. You want to have
some whitespace on board area where
they can actually put up their planning sheets. And you also want
to have space for the other non team
executives as well. Now you also may have external individuals that
need to dial in as well. So you may you may need to have breakout rooms as well because with the best
will in the world, what I've seen in my experience is that mostly you are going to have some people that are not
gonna be able to make it. You need to identify
that upfront and make sure you've
got breakout areas so those teams can actually go
there and then come back. So one-tuple I would say is you want to make sure that
they don't just sit in their own isolated breakout
areas because otherwise, you're not going to get
that rich interaction that can ensue across the teams. Okay, so the next thing
challenge we have is clarity. So what do I mean by clarity? So the first thing is
clarity of outcome. What are the outcomes we're
trying to achieve, right? We do that by making sure that
we've got a clear vision. And we also got
well understood and clear features as well for
all of the teams to work on. So we want to make sure
that at the beginning, even before the PI planning, the teams are familiar with the features that are
coming in and they clearly, clearly understand
what the outcomes for that upcoming pi r. Now, another thing that we want to make sure is that
they, they clear on, especially if the first time when they're doing it
is a teams need to be clear on exactly
what they need to do, what is the process. So that's also a very
important thing. Thirdly, as I said, value may span multiple teams, so teams may be dependent
upon one another. We need to make
sure that we have, we have a mechanism to identify when the value spans
from one team to the next. So we need to make
sure we've got our program dependency
board over there. We have designed this session in such a way that we can extract all of the dependencies that span the multiple teams as well. Now, it would be really easy for us for each team to just go away and actually
create their own plan, which would actually completely
be defeating the purpose. What we're looking
for is an integrated, coherent plan that integrates all of the other plans as well. So we want to make sure that
where the dependencies, those are called out, where there's impediments
or other risk factors, those are taken into
consideration and we come up with a yes, a plan for their
Agile Release train, but also for each of the individual teams
that fit together, that are integrated and work well with one
another and take into consideration all
of the challenges that are likely to occur during the upcoming
PI as well. Okay? And finally, what we have
is each team may have, the reality of the situation
is that each team and even individuals
within the team may have varying different
levels of agility. So they're not all going to have the same level of understanding. And so one of the things that we want to make
sure that we tailor our training in advance
to make sure that all of the teams are starting off
on a level playing field. And we do that by providing
packs, team packs, and training in advance of PR
planning to make sure that everybody understands exactly
what is required from them. So there you have it. So we've got the outputs to four outputs that you would
expect from PI planning. We've got some challenges over here and on the
upcoming videos now, I'm gonna be talking
about how we can start to work through and actually
solve these challenges. Okay, So this is
what PI planning is all about and what
I consider to be the top five challenges
that we need to overcome to run a successful
PI planning event. So to learn how to do this, stay tuned for the
upcoming videos where we're going to
talk about all of the tips and ideas on how to overcome these challenges so that you can have a productive, fun and enjoyable
PI planning of it. See you soon.
3. Session 2: PI Planning Preparation: Okay, welcome to
the second video in the sprint zeros PI
planning series of videos. We've discussed already
the challenges, but now I want to talk
to you about what is the solution to all
of these challenges. So I've worked in, as
I've mentioned earlier, I've worked in a lot of organizations and
we've implemented a large number of PI planning
events over the years. One thing that I've
found is the number one, the most important thing that you can do when
it comes to coming up with and getting ready for
a PI planning event is yes, is the P what exactly? It's preparation. It's the most important thing. Now, if you have attended
the leading safe training, the leading safe
certified training, whether you've done
that with myself or with somebody else. You may have looked at
the manual and within the manually actually
talks about PI planning, the first one being chaotic. Well, my experience is
quite the opposite of that. And I would say the only time your PI planning is chaotic is when you
haven't prepared properly. So the question is, how
do we prepare properly? So that's what we're
gonna be talking about in this video. So the three thief, three main things
that we need to focus on when getting
ready for PI planning. The first thing is, obviously, it's a large event. There are large
number of people. Remember now the
PI planning event has practically the
vast majority of people on your Agile Release strain that by its very nature
is a large events. So there's a lot of coordination and there's a lot of
preparation that's needed to make sure that
this is a great event that people not just get some
productive output from, but hopefully also enjoy
themselves as well. So let's just have a look
at a series of ideas, tips, things that I
would like you to think about when you are getting
your PI planning event ready. So the first thing
I would say is, I would suggest is, you know your numbers. If you look at the theory, it says that everybody on the Agile Release
train should be there. Now in practice, what you may find is in some organizations, they may, they may hesitate at trying
to invite everybody. So who would be
coming to this event? So I'll talk to you about the textbook
first and I'll talk to you about in the real-world
how you would do this. So the first one is
everybody in your team. So all the people for your
team would be invited to that. So all of the teams when you're agile release train
whether that's, you know, as you know, five
to how many do you remember? 12, right, five to 12 teams
on your Agile Release drain. And you would have
those all invited. Okay, So we're talking about upwards of a 100 people
potentially, right? The next one is all of the people at the
program TO, okay, So we're talking about people's like product managers
were talking about the release
train engineers were talking about the system, architects were talking
about the business owners. We're talking about
stakeholders. We're talking about people
that I helping release, integrate and all those
other roles that sit and support the Agile
Release train at that level. And we're also talking, have involvement
and participation from the portfolio tier. So you may have
African is over there. You may have lean portfolio managers
over there that are supporting the event as well. So it's a fair number of
people there now, right? So as I said, you're
going to be talking about upwards of a 100 people. Now. That's in, that is
the theory of it. Now, where have I seen? What have I seen in practice? People doing, people do too frequently tend to
circa, well look, we're not going to invite
everybody to the team, from the team to the event. So what we would do is we will might invite, I don't know. Let's just say the scrum master is maybe the product owners. We'll get a few of the
key people from the team. What I found has worked
actually in the past is, is that if you let the teams decide the subset who
they wish to send, four, represent them
because I think it's quite important that they have that power to actually
decide who is representing the team
and making decisions in terms of the
high-level planning. Now, remember what they're
gonna be coming out with. The team is coming
up with a high level a high level roadmap, if you'd like at the
team level for what, for what they are
actually doing. So you want to make sure that the team is happy with that. Now at the program
level, as I've said, you've got a few people, probably not as many people as you would have at
the team level. So there's not that much
you can do over there. But what you could have
a look and see is, is that if there's on
stakeholders and other, other individuals that
aren't, aren't really needed. Now just a warning
point over here, regardless of whether
you're looking at the team program
portfolio level, one of the magic elements
of PI planning is that you can get whatever you need done because you got access
to all of the right people. So just be careful about not leaving the wrong people out. And you could end up with
sort of like investing in large amount of money
and have a large event. And you have lots
of people coming. But because you've left
out two or three key, key individuals,
you could start to derail the power of the venue. So just a warning over that. Now obviously, we've got so many people you got
to make sure that you've got the right a venue. Okay. Right. Venue over there. That is has the right size, but also you're
looking for another, a number of things now. So how I look at is we're not going to have
a look at the venue. The first thing I
look at is to say, okay, what's the overall
size of this now, what's the kind of layer that we you would have you
would either have what's called a banquet
layer, Capillary layer. Okay. The other thing that you
would want to have is, is that for each team, you could give
them an area where they could sit and
they could plant. Now they need either
some wall space. Are they going to need a flip
chart and an easel where they can actually put the
outputs over there as well. You're also going to need space for a large program board. Now remember that
you're going to need a column for each sprint. So that could start
to add up to quite, quite a horizontal space. And you're also
going to need rows for each teams as well, okay? Because that's where you're
going to need to work out the dependencies
across the teams as well. So you're going to
need a large space where you can have the
program board over there. Okay? Also remember in the
beginning of the event, this assuming you're going
with a two day event, which is a standard, standard
PI planning duration. Then at the beginning
you're going to need a vision, right? So you may have the need for a projector and all of that kind of stuff as well.
So just bear that in mind. You, you would need, need to have a look
at that as well. Also, you want to
make sure that you, in addition to these folks, you're going to have
additional stakeholders as well, right? So you wanna make
sure that there's space for those folks as well. Alright, now, the third
thing that I would want to say is that lockdown diaries. This, the beauty of Agile is, is that you've got
a timebox and it's fixed and you know what's
gonna be happening. So locked out, all of
the team level diaries, locked down the program diaries, make sure everybody
knows way in advance. Now remember, as I said, if you've got one
key individual that happens to be on
holiday at this time, then it could derail
the whole event. So clearly we don't
want that to happen. So we want to make
sure that people know well in advance
so that if they need to take the dates into consideration when planning their holidays,
they can do that. So this is very, very important. Now, there's no reason really why you can
actually just block out the ceremonies for the
next two, even three ***. There's no reason why
you can't do that. You could cancel
them afterwards if, for example, for any reason, the Agile restraint is
not sold so long formed, but at least you've
got people's diaries locked out of there. Okay. So that's the first thing. A couple of things that I
would just ask you to have a, have a think about
and to prepare for. Now. The next element that we need to think
about is the inputs. Now this is probably
one of the challenging, challenging elements when
it comes to actually getting The PI
planning event ready. And it's the one that has the
longest lead time as well. So let's have a look at some
of those elements to that. So now remember, we
need to get the vision. You should have a vision anyway. If it's like assuming look, you've, you've done a PI
planning event before. It's not your very
first PI planning. You should have a vision
already ready, right? So if it is your
first PI planning, you just need to
make sure you've got a clearly articulated vision. You've got the, the
senior executives and the business owners and the product managers are
able and willing and to articulate what
this vision actually is. So, so you wanna make sure that you've got clarity
on that as well. Another big thing is making
sure you've got well formed, a well-formed feature backlog. Now, this is where a good
product manager would really help to support you in getting your
feature backlog ready, working with all of
the stakeholders. Do you remember who some of the key stake holders
it'd be working with? Well, yeah, I hope so. Well, it's the business owner. It's the release train engineer. It's the architect's.
They'll be working with all of these folks and they will be putting together these
features as well as also, of course, the product
owners at the team level. So all of these will
be working together to put together a coherent
set of features. Now from experience,
what I find is, is that this is the bit where
people struggle the most. So they either do
one or two extremes. They all do one extreme
where they were. They don't worry at all about
much about the features. And so they come up with
a pretty awful features. Or on the other hand, it goes so overboard that they almost
end up in a waterfall kind of scenario where
the features are really verbose and then not clear. The acceptance
criteria is not clear. And it takes him for ever
to put these together. So what we're looking for,
something in the middle, you want good quality
features by remember. Supposed to be
short for a reason. They're supposed to fit
on a card for a reason. The idea is, is, is that it's not supposed to
take that much time, right? So just bear that in mind. Now, the other thing is, is that once you've
got the features, you want to make
sure that they are prioritized to
demonstrate that value. Now in the beginning,
it may be less formal. Afterwards as you
become more mature, you can have a look at some of the other algorithms
and other things like weighted shortest job first and algorithms like that as well to help with
the prioritization. But really important
to make sure that the features are prioritized according to what is
the biggest value. Now, lastly, very important
is the architecture, is the architecture and
the architectural runway. So we want to make sure
the things that we can't change that easily, some things that are not easy, we can't iterate over
that then very easily. Then we want to make
sure that we have a good understanding of
that well in advance. So for example, from a
systems point of view, if you are using a
specific technology, you might want to make
decisions around the kind of technology you want to be using. Because afterwards changing and technology midway
through can be, can, can involve
some regret cost. For example, if you're doing
a non, non IT example, if you're developing a building, you want to know the
size of the scale of the building so that you can
lay the foundations rise. Again. Not easy to
change the foundations afterward without incurring
a lot of cost. Okay? So these are the kinds of
things that you would think about it that would be included in an
architectural runway. Also have a think about things that have a long
lead time as well. So if you've got a certain
architectural decisions that may involve
the use of certain or the technologies are
certain approaches or certain resources and they
have a long lead time. You might want to
have a think about those kinds of things as well. You also want to make sure that the architecture, the
features, you've, you've had a look and see
which features actually have a need for architectural
support as well. Okay? So that's the
second element there. Pi planning inputs, very important if I would
say where most were, most release train engineers and product managers
and other people that are putting this
event together where they could go wrong is probably, is here is making sure you
haven't got the inputs. Look, if you've got
garbage inputs, the chance of you coming
out with something amazing is going to
be really quiet, low. And it's also going to make for a pretty frustrating
experience as well. So I can't emphasize
that enough. Okay. Now, you've got you've
got the events, you've got the venue sorted, you'd know your numbers, you've selected the right venue, you're on a roll, okay, you've locked
down the diaries, you've got all of
the inputs now, I wish I could tell you that
was enough, but it's not. I've had this scenario
where we did all of these things and things
still went wrong. And where things went
wrong was that the, the teams, the individuals are actually doing the planning. They were quite
shocked because some of them didn't
have that level of maturity and agile understanding
in terms of how to, how to plan and how to
involve themselves, coordinate with the other
teams in a meaningful way. So what I found
over the time is, is that it's really important that we do a couple of things. So the first thing is we make sure that they're familiar
with the features. Don't shock them in the
beginning to say on the date. So here we go. Here's some features of
you go and start planning. A little bit of wall is
too little, too late. Make sure just a little bit
in advance of the PI plenty. You've shown them
what's coming up. They've got an idea
of what's there. If ideally, if they could, if they could t-shirt size
them or have a look at them, that, that would be useful. They have an opportunity to ask the architects what kind of architectural in part two implications
that feature could have. So that's quite important
now aside from that, the other thing that you
want to be looking at is overall training and guidance
on PR planning if it's, if it's your first time. So you wanna make
sure that people understand what's actually
expected for them. Lay out step by step by step. Make it almost dummy proof. You're going to
have some people in your PR planning event. There are masters,
understood, I get it, but you're also going
to have people that are completely new to Agile as well. So start from the most basic, have a step-by-step guide. I have a team pack that I give
out to every single team. It's actually a
written printed out. No, it's not very ecologically
friendly or the other. But really they need
that because imagine them moving around if they've got something
in their hands. Okay, how do I do this part
of the planning session? It's really useful and I
can't emphasize that enough. Okay, so that is the video
for PI planning preparation. I hope you found that useful. Now, I look forward
to seeing you in the next video where
we're going to take this a step further. See you soon. Thank you
very much. Stay tuned. Speak to you soon. Bye.
4. Session 3: PI Planning Event: Hi and welcome to sprint zeros
PI planning video series. We're in the homestretch now. We're on the third video of the PI planning
series of videos that walks you through how to plan and effective and hopefully
a fun PI planning event. Now, so we're on the, on the big event now it's going to be
talking about how do you actually manage
your PI planning event? How do you run it? So you prepared really well. You've looked at the second
video that we talked about. You've done all of the things to manage a large event
that we talked about. You've trained the
teams up and yes, you've even got very good inputs coming into your PI
planning session. You've got a clear vision that's been articulated
well by the executive. You've got features
that are well-formed. Guess what they ordered in the
order of the maximum value that that can that's required
to deliver that vision. You understand
your architecture, you are able to articulate
that and you've actually got what we call an
architectural runway. So now you're all prepared. What do we do now? That's the question. So let's just take a step
back and let's ask ourselves, what is a PI planning event? What is the purpose of
a PI planning event? Now, the purpose of a
PI planning event is to create a plan that clarifies the goals for the whole
agile release train for the upcoming
program timebox, which is, if you remember, is called a program increments. If you remember, do you
remember how long it was? What's the time
timebox duration? If you said eight to 12 weeks? Absolutely. Ten weeks tends to
be the default. In practice, what I'm seeing
is most organizations are going for 12
week increments. At least the ones that I've come across are going for
12 week increments. It fits quite nicely
into the financial, uh, windows that they
have over there as well. Okay, So now what we're
gonna do is we are going to look at how to actually run an effective
PI planning event. Now, there are two, there are two
approaches that you can use to run your
PR planning of an I personally have run
PI planning events that take place and complete
within a single day. And I've also run
PR plan events that run over a span of two days. My feedback
approximately I've done about 40 per cent of
the PR plan is that I've run one day events and a brown 60% around two day events. Now to day events, or the standard recommended
duration for a PI planning. Using, if you look at the official scaled
Agile framework guide, I prefer them as well two days because it's a
little bit more relaxed. One day tends to be a
little bit more aggressive. You need to do a
little bit more effort in terms of the planning, the teams need to know
exactly what they're doing. So there's more effort in terms of training the teams as well. And so two days, the feedback that I got is
two days is a more relaxed, more fun, more fun
event as well. So what we're gonna
be talking about today is the two day event. I have a online PI planning in detail video series
which I'm putting together. And that's gonna be
running through both of the events step-by-step
in much more detail. But for the purposes of today, we're gonna be focusing on the second on the second option, which is a two-day event, right? So we talked about the
creation of a plant. We need to clarify the goals
for the upcoming program, increment planning, but the plan has been
taken into consideration. A number of things is
taken into consideration. The capacity of all the
teams is taken into consideration all
of the dependencies that you may have across the
different teams as well. So these are all factored
in and it's taken into consideration any
impediments and risks that you may have. And once it's taken
in all these factors, then you come up with a plan. You circuit. This is a
plausible roadmap of how we can execute over
the next increment. Okay, so that's
basically what the purpose of the PI planning if n. So now let's walk through
how we would actually go through a two-day
event that day one. And I remember the first thing that I just want
to call it again, even though I've mentioned
it in the previous video, is that this is ideally
a face-to-face event. So you want to have a
location where you've invited everybody to come and you've invited them
well in advance. And I encourage you
if you haven't seen the second video, please, please go back and look at
the preparation side of things because I'm not covering that material in
this video again. But suffice to say is you've got a large event over there. You've got a large venue, is capable of holding all
of your teams over there. You may have some breakout rooms over there so you can actually communicate with teams and individuals that can't make
it to the event as well. Okay, so you've got this awesome venue and now
you want to get started. So how does it actually starts? So if you look on
your screen now, what you are actually
going to see is a, an example agenda, and this is an example that I
have run personally. Now, you can look at the
times not Please don't take the time as a given. This is something that was
setup for a specific client. Take into consideration
their specific needs, but it will give you an idea. So my general approach of four for this particular client wants to have a shorter version. So we had a vision between 910 AM in the morning and
in that in that slot, what we would do is we would
start off with articulating, of course, as you've
probably guessed the vision. But then once we did that, we would have a small slot, maybe ten minutes to
talk about the vision, where the executive would come in and talk about the vision. And then we would have the
release train engineer talk about the, about how the last PI, the last program
increment actually went. And some talking about metrics and achievements
and other things, and how far along the grand
vision they have gone. And what also are you looking
to do now for the next PI, that's where the product
managers come in. All the business owners are, the executives may
come in and actually talk about what's coming
up in the next PI. Also, we have an
architectural slot in there. You would want to have
that there as well. And also planning guidelines. So they're split up into probably about five or
six different slots, five or ten minutes each, and that will cover your whole vision for the morning now, tend to keep your high-energy, really snappy, and keep it
a bit lighthearted and fun. But also make sure that they get the information they need so they understand
clearly where it is, where going, and also what are the features that are coming
in at a broad-brush level? Ideally, the teams,
if you looked at the preparation video, you've made sure that you have during the preparation
for PI planning, the teams have looked and I are familiar with the
features that are coming in. Okay, so that's a
nine to ten session. Now after that, what
you have is you have what I call planning one. Okay? And so in that, what you would do is
you would identify the features that each
team is working on. Now the two elements
to this, right? So one is a feature may be done in its entirety by single team and
that's great, Great. So if you've got a fully
cross-functional team, you will a feature that is, that is a delivering real
value across all your system and all your different
silos. That's great. And you've got to an individual team that's able to
deliver on that. Fantastic. Now sometimes
there's not gonna be the case. Sometimes you're
going to find you gotta feature, oh my God, I need three teams to work on this to actually
be able to deliver that. That's fine too. But what you do
want to do in this, in this session is what you wanna do is
you want to make sure you've identified that, okay? Now, in practice, I tend
to identify that before we walk into PR planning because we've familiarized
with the teams, with the features and we know which teams are
gonna be owning that. So it comes in the
form of a matrix. And it shows which teams
are owning the features. So when we say a t
and individual team is owning the features, they're responsible for
getting the features. All the different individual stories from the
different teams, pulling them together,
making sure that they get To done as well. Okay, so that's the first thing. Now the other thing you want
to make sure is that we look at each individual team, looks at their own
team capacity. So they are, have a look
at the previous PI, see what they have
actually done. And they can then
determine based upon what they've done
in the previous PI, how, what they can anticipate
in the current PI. Now obviously things
like holidays, if you've got like a if you've got a PI with we've Christmas come in
in the middle of that. Of course, that needs to be
taken into consideration that that can have quite a large impact on
new capacity as well. And also if you've got shared resources which,
which, which is, which can be a problem,
you need to just bear that in mind and take
that into consideration. Okay? So you don't tend to 11. Now we've gone PI planning one, or they've identified
the features. You identified, the teams understand what their capacity
actually is fantastic. Now, in PI, in planning to now. What you wanna do is you
want to make sure that you've sized features as well. So the teams are now sizing
them. They made them. They may want to use
what we call T-shirt sizing or they may want
to use feature points. I don't particularly mind. I give the teams the
translation there to say, what's a small,
extra small, small, medium or large,
which is referring to the T-shirt sizes and how they equate to feature
points as well. Okay, so I'm planning to, we've sized the
features as well. Then we start to take the
features and we break them down into
story placeholders. So very important point to note, and this is where people
slip up quite a lot. Sometimes people actually start to take the feet of
that and their break. All of those out into the brake. All the features are into as
many stories as they can. And the challenge with that is, is that you end up descending
into a waterfall model. So what we wanna do is
we want to be careful about just breaking
up the features that are in the early sprints or the features that are
spanning multiple teams. You want to call out those
specific stories so you can identify the dependencies
across those different teams. You want to start to map those out on the dependency board. And you want to make
sure that if there's any high-risk
features that you're concerned about and you want to understand a little
bit more use, you split those down. That's perfectly acceptable. If, say, for example,
you've got a PI of say, I don't know, a
12-week PI, right? It's perfectly acceptable for
you to say, I'm going to, I'm not going to break down
the features that are in, in, in iteration 45, right? I'm just going to
put those there completely as their own, especially if the
team is able to complete them in their entirety. Because what we actually want, we don't want to
happen is we don't want the team to be
moving away from that just-in-time planning that's so powerful in any Agile approach. So that's a, that's a point that I want cool out there right now. So then after the
board is useful, what you could do is we do
a Scrum of Scrums where you have a board up there and
you're actually identified. Imagine you've got like 12 to 16 teams now they're
all playing together. You want to make sure
that everybody's on track and find out if
anybody needs any support. If there's any need support from either other Scrum Masters or product owners or from the product manager or from the restrain or
whoever that may be, then you can identify that
during the Scrum of Scrums. So that's the next thing. Okay, so now you've
worked through, you've had some really great
networking in the beginning. And remember this is about face-to-face
communication network. In many of these people won't have met each other
before at all. Especially if you're
running like your first PI planning event may maybe they are meeting
each other for the first time, depending on the type of
organization that you have. So it's a fantastic opportunity
to do that networking. So you've started off
with that coffee. You've done the
vision, you've done the planning where you've
identified the features, you've identified
your team capacity, you started to break out
those features into stories. You size those features
as well, and guess what? You also identified. Started fog all the teams are Alright, fantastic, Well done. You can pat yourself
on the back. You've done a great job so far. Now comes lunch, so
you're gonna give them I suggest you give them
depending on the size. Look, if you've got like a
100 or the people in your PR, it's gonna take them time. And especially if you've
got like a pinch point, like maybe if you've got a venue providing
you with lunch, then sometimes it may be quick, so it may take a longer time than if you
had a shorter session. So what you may wanna do is make sure you give them
a full hour of lunch, but I'll leave that
up to you to decide. But just bear in mind
numbers can have an effect on that as well. Okay, so give them a
good lunch because you're gonna be retired. Okay, now after that
you're going to have the natural drop in
energy after lunch. So you wanna give them a
little bit of an energizer. Sometimes you do a
little bit of a game. Sometimes we get them
up. We just get them up to get them to stand up. And we didn't just
to stretch or to do something or to play a, play an active game
with one another. And that gives them a little
bit of a boost as well. Okay, Now, in the
specific example that I've got on the screen, what you're going to see is you're going to see
that we have got a sync meeting now in
this particular case. And I wanted to keep this specific example in
here just to show you, we had another
agile release train that was running as well, and they will cross team
dependencies over there as well. So what we did is after
the, after lunch, we identified those dependencies with the other edge already
strained because one thing I did neglect to
mention is that you would ask the teams to identify any cross team dependencies in this specific
instance, at least. And then that sync meeting
would be that conversation with our US counterparts
in this specific example. Clearly, if you don't
have another agile really strain that you
need to synchronize with, then you just cut that. That section out. Okay, let's move on now. So now after that, what you would want to be doing, the teams coming
back from lunch, they've done their energizer, and now they're ready to
continue their planning. So they're going to break down the features into
story placeholder. So now if you think about it, what you actually have is you've got this
situation where imagine, let's just say for
argument's sake, you've got a number of
teams over here, okay? And each of them have come out with their plan
over here, right? So that's the team plan here. Each of them have come
out with their team plan over here. Okay? Now, what you don't have
is you don't have I have a an integrated
plan yet at this point. Okay. So what they have done
is they've actually taken the features, right? Just bear with me a second. So they taking their features, we identified you remember we identified how those
map across all of the different teams
and we break those out into each of the
different teams, right? So the teams know
they're working on and what they've
done is they've, they identify their
stories, right? I factor probably. Let me just draw
something here, right? In a bigger way over here. So imagine that
the PI plan, okay? And so there will be identifying their stories over here, right? So you've got a few more stories over here in the earlier ones and you've got fewer stories as we continue on down because we need the plan to be what we call emergent. And I'll talk about that more
in a separate video because we don't have the time for
that in this video right now. Okay? So the problem that
we have is what we do not have is we do not
have an integrated plan. So what I mean by that is, is that we've got isolated individual plans
at this point, right? So what we need to
start to do is we need to start to try to ident. We start to need to
encourage the teams to discover the dependencies that they have on one another. Okay, so now imagine this team over here
has got a dependency. Let's just call them
team a and team B. Let's just imagine that team a has a dependency on Team B. Now they're going to say, well, I need this story
in this iteration, iteration one or two
or whatever it is. And so now they're going to have that negotiation that
that's gonna go on. Okay. So that's what they
will be doing in a, in a planning, what I
called planning three. Okay? So once they've done that, there'll be doing
that for a while, give them a bit of
a coffee break and let them continue to do that. Now what you find is, is that if you will, if you've done this right, you will have a
program board, right? It was a program
dependency board. Looks something like this. Okay. So what you have is you've
got your, along your columns. What you have is you have
your iterations, right? So let's just call
this iteration one iteration to
iteration three, and it would go on, right? Okay? And then you have
your teams over here. This is called a team a, team B, team C. Okay? And so what you would have
over here is this is, this is a map to identify
any dependencies you have. So if T is delivering
a feature one here, and, but it requires
a story from Team B. This is how you want that
to actually be represented with a string or a line between
the two of them, right? And so what that means is, is it facilitates
that communication at the right time to say,
Hey, this grandma. So from, from TMA can
have a conversation with Team B just to check to
make sure that they are getting that story
coming through. Okay. So now we've got that, we've got that need to identify
those dependencies now. You will have that two, don't worry you if you're, if you're running this PR plan, even use your, your, your dependency board is
allowing empty for the first. Even too, Up to, towards the middle
of planning three, Don't, don't worry too much
about it, that's fine. It's perfectly normal because the teams need to work
out what they're doing individually and then
we can start to mesh the team, team plans together. Okay? And so now during
team planning 34, you want to start to identify the cross team
dependencies. Okay? Now, once you've
done that again, you'd have another
checkpoint where you do maybe a Scrum of Scrums. And then after that, what you want is towards the
end of the day, you want to have an opportunity to everybody to go
through the team plans, all of the different team plans. Now, what you just got to bear in mind that
if you've got like say, I don't know, if you've got, say ten teams, right? And each of them takes six
minutes, That's an hour. So you've blown an hour, right? So just bear that in mind. It may feel like if I
give the team like, I don't know if ten or 15
minutes, that's not very long. But depending on the size of your trade is start to add up. So you just got to bear that in mind that you need
to keep the time, the term quite short
and it needs to be quite succinct as well. Okay? Now the day one
then wraps up with a management review with a management and other key executives and
have a look at that. And you can, okay, given the given the overall
vision that we have. This is the vision
that we have for the Agile Release train. Great, That's fantastic. Alright, this is what we achieved in the
previous PI, okay? This is what we were
hoping to achieve or at this is where it's
kind of looking. What's that delta there is any adjustments
we need to make, all of that kind of good
stuff that's gonna be happening towards
the end now it's a long day, remember, right? So some of these costs
can be pretty good. But it's gonna be probably after five o'clock,
I would say right. So you wanna, when you're
setting up your agenda, just make sure that you
set the expectations. What I find is better
to set the expectations up, upfront in advance. So people look, especially for executives and other
people that are gonna be involved with
the overall vision. Making sure attainment
of that vision. Probably not going
to be going home till 6630, something like that. Okay. But there you go. Right. Okay. Day one. So now we've done day one, everything's great. Day too. I've seen from
experience tends to be a little bit more relaxed
because the teams are now, hopefully if you've done a good job of broken
the back of the plan, not entirely there yet. But you start off with
your networking, okay, you could start a little bit
later if you wanted to write because you're first-day made style at 830 and next day you
might say, you know what? Teams will be a little
bit now could we could even start off at nine o'clock. Okay. But that's your
decision obviously, right? So you spot you do want to have a morning coffee or networking
session where people can talk to one another that may not normally be
talking to, right? Because that's where the
magic happens, right? You're having a conversation with the role that you may not normally talk about
or talk to in your, in your in your daily, in your daily work. So that's useful from
that perspective. Okay, so now we continue doing the planning for the
teams just really, this is just a point for
the teams to continue. They, they continue mapping
out the dependencies. Now at this point, what they're doing
is they're mapping out a number of different
outputs as well, right? So there will be a,
what are the outputs? I'm just gonna, I'm just
gonna clear that down to give a little bit of space here. Alright, so the outputs
that we have from the PI planning are
basically the first thing. As I said, obviously
what we have is we have the program
dependency board. Okay, so that's the first thing. So that's the overall
dependency board that we have that's there. Okay? I suppose probably
more important than that is your PI goals
obviously, right? Because that's what the
goals you are hoping to achieve to support
your vision, right? So that's the PI goes. Now that's the PR goes for the whole agile
release train. Okay? And so that's important to know. So you've got this really
pretty big vision, this larger Agile Release train. And you've, you've delivered some goals in the previous PI. Now you've got a set
of goals that you need to live it in
the next one, right? Okay. So that's that's,
the next thing is, is that you've now, it's important, really,
really important too. I can't stress this
enough, right? This is one of the
reasons why safe gets a bad rap in some, in some parts of the
Agile community as well, is because what people actually
do is they don't treat the output from PI planning
as an emergent Plan. They treat it as a detailed sprint plan
for like five weeks, five sprints, which
is just awful. But you don't wanna do that. So the teams are coming out with team roadmaps is what are, how are, how I like to
think of it, right? Team level roadmap to k. So it's saying that roughly these are the
features we're going to be delivering over the next
five sprints, the features. And look, we've broken out some of those stories and we know for the next sprint
because that's just a couple of days away. But for follow-on sprints, we don't know for
roughly these are the goals that we wish
to achieve, okay? The next thing you've
got are the impediments. And so by impediments, what we mean is these
are and risks, okay? So you've got and
assumptions. Okay? Alright. So by impediments, we mean look, you gotta block and now
we don't have a server, we don't have this resource. We have this challenge
with the API that stopping us to do something,
it could be anything, it could be anything from
either know something silly from this user doesn't have
access to something bigger. Now, the one thing that I would say though, to point out is, is that at this level you're
not gonna be putting out team level impediments that the scrum master should
resolve themselves. You're talking about
more high level stuff. You're talking about
things like you got challenges with
resourcing, okay? Maybe happening. You've got large architectural
challenges that may be happening that need to be sold at a program level, okay? Now the difference between
an impediment and a risk is an impediment really is a risk
that has been actualized. It's there. A risk is something that
may or may not happen sometime in the future
when it occurred, that risk now becomes
an impediment. Ideally, you want to obviously minimize your
number of impediments. Or as, or at least you want to be able to jump
on those really quickly. Every good release train
engineer will have a hot list of the impediments and that's the first thing they're
going to come in. They're going to tackle,
and I'm going to solve those because they know. That an impediment is deadly
for the execution of a PI, of an SRE, of an agile
really straight. And then obviously assumptions
are really important that I frequently left off as well. Okay? So these are
the outputs that you are expecting to start
to come together now, by this stage, right? Now, if you look at
the agenda over here, we then have another lunch. You have a, another art sync meeting in the example
that I've put over here, because this was
like an example that had that had another
Agilent is trained, as I mentioned, you've got these sheets put together and now you've got
a coffee break. Now finally you do
a final review. Now, this could be more in a, more in depth and day one, you've got more
detail now you've got all of the outputs there. And you've got something, something quite concrete to
actually have a look at. Then finally, what
I would say is, is that you want to
make sure that you wrap up all of these planning really carefully
because it's very easy to go off on a high and
you've got all this output. And if he's not
carefully taken off from that room is not
carefully collated, then there can be a loss between the PI
planning day outputs, whatever machine or
whatever tool you're using to support your PI execution. So that last bit
is very important. You want to make sure you've
got like a retrospective. You wanna do a retrospective
to see how well it has gone. And also we have
something called a confidence for at the
end of that, okay? So your confidence vote is
you want to find out how confident people are in your
overall Agile Release train, plan for the next PI. Alright, so quite a few things then I'll be putting on videos, do, doing deep dives into each
of these different areas. And also if you need any help
at all, please let me know. Now you've got three options in terms of the kind of support that I provide in
terms of PI planning. The first one is that
every fortnight I have a few slots that I use to help people
with their PI planning. It's more like a Q&A, any help that anybody needs. Now can't give this
to everyone due to the volume of
requests that I get. But if you do have any
specific questions, if you need any help, then you can fill out the
form and if possible, can't make any promises,
but if possible, then I'll try and give
you a little bit of time to actually
help you with that. The other option you
have is if you have API planning event and you
are the one to take it to the next level or it's the
first time you're doing this. It really does pay to help get some help with actually facilitating a
professional event. And that's what I do. So you can you can also
contact our offices for that. Again, details will be
on the page for that. Finally, I'm putting together an online PI planning
step-by-step training session, which you can, you
can sign up for. And again, you can you can
details of that on this page. Okay, So look, I hope
you find that useful. I'm very excited for you. If this is your first PR
planning event, It's awesome. You'll love it. I've been doing this
for many years now. 2021 PI planning events. Now I've helped support,
prepare, facilitate, and believe me,
I'm still really, really excited when the next
PI planning event comes. I wish you the same
sort of excitement, passion when you, when you are doing your PI planning
event as well. And as I said, if you
need any help at all, please do reach out to me all of us hope you find this useful. Thanks very much. Bye.
Ahmed Syed
