Step-by-Step Large Scale Agile Programme Increment Planning | Ahmed Syed | Skillshare

Playback Speed

  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x

Step-by-Step Large Scale Agile Programme Increment Planning

teacher avatar Ahmed Syed

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Lessons in This Class

    • 1.

      Intro: Scaled Agile Program Increment Planning Overview


    • 2.

      Session 1 : PI Planning Challenges


    • 3.

      Session 2: PI Planning Preparation


    • 4.

      Session 3: PI Planning Event


  • --
  • Beginner level
  • Intermediate level
  • Advanced level
  • All levels

Community Generated

The level is determined by a majority opinion of students who have reviewed this class. The teacher's recommendation is shown until at least 5 student responses are collected.





About This Class

About This Class

If you are looking to learn how to plan for your large Agile Project or Programme, this class is for you. Ahmed has spent many years launching, transforming and planning large Scale Agile Programmes using the Scaled Agile Framework. You'll learn tips and tricks that he uses to ensure that you have a valuable, inspiring yet realistic plan for your Agile Release Train which may consist of between 50-125 people.

In this class you'll learn:

  • What Program Increment Planning is
  • What are the key inputs and what do you have to look out for
  • How to prepare such a large event so that you successfully create a powerful plan collectively whilst having fun!
  • How to avoid common pitfalls and problems.
  • What you absolutely must do to ensure that you have a successful event.

You can also find Ahmed here:




Meet Your Teacher

Teacher Profile Image

Ahmed Syed

Level: Beginner

Class Ratings

Expectations Met?
  • 0%
  • Yes
  • 0%
  • Somewhat
  • 0%
  • Not really
  • 0%

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

Take classes on the go with the Skillshare app. Stream or download to watch on the plane, the subway, or wherever you learn best.


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.