SAFe PI Planning or Program Increment

hello friends this is melody once again welcome to agile digest this is another video on scaled agile framework as many of you already requested for making some videos on another topics on scaled agile so this is what we came up with a PI planning as everyone you know p.i planning is one of the most important part of scale agile and that's the heart of our scale agile framework so we will try to understand what exactly the p i planning in very details we'll talk about each and every part of p i planning day 1 day 2 how we are making the dependencies how we are breaking down stories into features how we are doing some story point estimations or we are making our program board what are the different kinds of program bolts we have and many details and this particular slides or the PowerPoint that I have made or this particular video is will be little Lindy so say stay tuned in case of you have any questions any comments you can type it down in the comment section I hope you will like this video and if you like it please show your feedback by subscribing to us click on the bell button as well without spending much more time let's start with the PI planning as you already know that we have covered one of the video on the fundamental of scaled agile frameworks and where we have already learned that scale agile framework goes on multiple PI's or program increment and each program increment have four iterations by the recommendation of scalar jelly it not necessarily will be having only four you can have five or six but scale as well well recommend is you should have for construction iterations and after that you will be having 1 IP duration IP in the sense innovation and planning iteration so let's try to understand that if we have three or four teams and everyone will be working on four iterations at every trations each team they will be working on development testing use many other activities they will be working now if I'm talking about four teams four iterations those all are part of one PE or one program increment one program incremental for development iterations or construction iterations and at the end we'll be having one I Pete relations we're in the I Pete relations we'll be talking about the P I planning we do some planning for the upcoming P I so each these four iterations are called PIH scope or whatever the PI scope we have that's my pi/4 pi-1 for an example similarly i will be having one next p i with three teams who are working or four teams are working they are working for iteration five six seven eight and that's my P I scoped to and similarly after these I'll be having one IP trations and start with my third P I so each P ie the four iterations under the P I is come after one IP trations now IP trations is innovation and planning iteration it's also have a two weeks of time and we'll talk about much more details in upcoming few slides let's try to understand a bit of each iterations what exactly we are doing at every iteration x' we are doing some kind of team events that iteration planning and then we are doing another iterations event that's my review and retrospective when we are closing the each iteration and that's happening for all the teams all the iterations when my four iteration is completing I will be doing my IP tration and remember that end of the every iterations all the team under the same P I are integrating their development and make a system demo so that system demo is definitely at the end of the every iterations this is just an recap of what we have done in the last video when we are talking about the fundamental of our skeletal framework will primarily focus on IP tration and over IP iterations we know that it's the same two weeks of iterations and in this two week of iteration the last week or the second week eighth and ninth we'll be working on our PI planning we may take some time on tenth and seventh based on how exactly our you know our solutions Slayer is there we'll learn that why we need that you may not need that if you just have only one co-located PII or one co-located alt then we may not need that we'll go into the next slide where you can actually try to understand that at the end of every PI planning we are getting some scope for the upcoming PA so here from this diagram you can see at every PI planning we are getting some scope of the upcoming Pai development so IP trations at the top what you are looking at we are having our first IP I planning then we are having pi-1 then we are having an another PI planning we are having pi/2 then we are having another IP trations and p.i planning under that and we are having our pi/3 let's try to understand what exactly we are having under that IP iteration will pick example of one eye pit relations and go into that so from here I can see we only talked about three hype literation but let's stick let us take any one IP trations and see what exactly we have within that so this is the state of my or schedule of my IP iteration where we are concluding one P I and about to plan for the next P I so the P I planning that we do on eighth and ninth day of your IP trations to plan what we'll be working on our upcoming P I so if you are doing i patricians after p i1 in the p i-- planning after that within that IP tration you will be planning for pi/2 let's try to understand that let's just talk about only the last week we have and last week we will take four days seven eight nine ten and within the seven eight nine ten what exactly we are doing so the seven eight nine ten if you are looking to this this is the time after every P ie when we are reaching to our IP tration within IP iteration second week eighth and ninth day primarily we are doing our p i-- planning and this is what we are trying to understand here now if you arrange this P ie instead of vertical if we have that horizontally so that we can see that every PII we are having one IP relations we are doing P I planning then we are having another P I or execution of the P I then we are having another I predation we are having P I planning and so on that's why we are proceeding and at the time of every IP tration this is the scope of my P I planning or this is the time of my P I planning when we are executing and this is actually run by one of our agile release train and will be going based on however agile release train is constructed this is how we talked about a RT now we will talk about the key points of having your P I planning so it's a cadence based systems it increased the rhythm and everyone works together P I planning is a heartbeat of art so if you are working on scale agile P AI planning is very much essential for you if you need to do for your P AI planning PR planning also increase the face-to-face interactions as you remember the scrum values or agile values and principles face-to-face interaction is much more beneficial so when you are working on agile so this P AI planning give a chance even if you are 125 or 150 members you get a chance to work as a face-to-face interactions now remember nowadays people have started working distribute lis many teams working from different geographical locations even then there are many tools or applications that we use for video conferencing and everyone get a chance to connect with each other so if when it is distributed or co-located doesn't matter the face-to-face interactions get the chance on working on that again there you know that there are multiple teams working together for one art or one program and they get a chance to align with each other so this is the P I planning you do plan for multiple teams when if you remember the iteration planning iteration planning we have planned for the iteration and P I planning we are planned for four iterations and multiple teams if you have 10 teams then also you are getting a chance to make a plan for all the teams and they can have the synchronizations with each and every teams in terms of dependencies or in terms of risk with each other and they work on a proper synchronized way and everyone get one common mission one common vision and one objectives to work for the next four iteration now a P I planning who facilitated that it's facilitated by your agile release train engineer so if I talk about you are co-located team so in case of your co-located if you are in working as a co-located team you will be having only two days eighth and ninth day of I Peter ation if you are a distributed team in case of distributed team you will be working sometime little more than two days but you will not be spending the entire day of eighth or ninth you may take some day at the end of on the last day for what purpose you will be extending your meetings because there is a difference between timezone at different places so it's not very much required that you need to complete it in two days if you are distributed if even if you are distributed and can be work from the same time zone you can complete in eight and nine days but if there is a timezone difference you may extend it for another half day of the ten or sometimes you may need to do some pre-planning even at the program level at the seventh day of your eye protrusion so that way we know plan so now one thing you need to remember if you are not doing p.i planning you are not doing safe safe is a very structured framework and all these structure is actually bind together by the p.i planning so if you really wants to work on scale agile framework and implement that p.i planning is very essential so there are a few prerequisites we need to have to work on p.i planning so as you know at the team level we have a product backlog in scale as aisle terms it called steam backlog similarly a program label we have a program backlog and in the program backlog will be having list of features the enablers the architectural requirement in terms of enabler or there are some non functional requirement maybe it can related to your previous retrospection x' or some infrastructure's anything can be possible as NFR now we have features enablers in efforts in our feature backlog and to work on your p i-- planning the first thing we need to identify the what is prescribed is prioritized top 10 features once we have the top 10 features then we need another of another objectives or another content that called business context what exactly the business context we need for the upcoming P I and then we'll talk about the product vision what is my product vision we will talk about the product vision but we'll soon try to understand who is actually providing all these information and we'll see each step by step how we can get that and also we'll be having our architectural visions our top 10 features and our product visions definitely get influenced from our feature backlog and this will be derived or provided by your product management your architectural vision also come from your NFS or enablers that you have now if I talk about business context where can who will be provide the business context business executive who will Prada provide your product vision your product management who will provide your architecture visions your CTOs or your Enterprise Architect or in a system architect you have they will able to provide you that architectural visions so primarily just take about CEOs an Enterprise Architect you know once we will done with the p.i planning what will be the output of peer planning will have a committed program objective so at a program level you know what exactly program I am NOT going into the details of program if you want to know what exactly I mean by program you can watch the previous video of fundamental of or understanding what exactly the scale as L framework is so once you have a committed objectives we also will get the Smart Objects smart is an acronym if you remember for acceptance criteria also we use this term it's a specific measurable achievable relevant or realistic and time-bound these are these are the acronyms and your objective should follow these acronyms and it is created by each team with the business value assigned by the business owners similarly we can have a program board where in the program board we highlight the new features delivery date features dependencies among other teams then we also have the relevant arts you have different themes those are not exactly defined as your development for example UX teams that also comes in and we map their dependencies with other team then we'll talk about teamwork distribution which team will be working on what stories and all those distribution also come up as a output of PI planning so when we talk about the readiness before you start working on P I planning we need to have some kind of readiness in our plan and to work on those readiness we need three different natures of readiness one is organizational readiness content readiness and facility readiness so organism already this planning scope and context that's one part of your organization readiness business alignment business alignment is also part of your organizational readiness and we will talk about what are the agile teams we have which team is primarily working for which product owner or what nature of features they are working on that's our organizational readiness content is very important and that will come from the business context we talked about the previous slide business context we have product visions and architectural visions these are the content readiness we start our PI planning with these three item these three content and we'll look into that in details when we go to deep dive into the our PI planning and also if you are running a two days meeting you need to have readiness on your facilities where you can accommodate 150 people or if you are working on a distributed how your video conference will work how everyone will communicate how everyone will share their program board all those facilities you need to have so facility facilities or tech supports similarly how we will start working on communication now let's jump into our p.i planning day one as you know these are the two days event will jump into our day one and before we go into details of this day one I have a small announcement that will be kind of a six to seven minutes of announcement if you don't if you want to skip that just proceed after seven minutes scroll your pointer after seven minutes he will able to resume in this particular video hey friends this is military I just want to give you a quick update on how we are collaborating and there are a few areas I want to just give you a message I know that many of you have subscribed and thank you for that many of you are giving feedback and I'm trying to recover or I'm trying to answer you or fix our way of recording the video and giving you inputs in that way just want to give you a quick update that there is another way we have started to collaborate much more better if you look into the screen we are just talking about our telegram group where we can have many job postings so you if you are part of this group you can get to know different jobs at different levels from master product owner or in some other technology areas also you can get notified and acted on that particular post secondly we have discussions on your job challenges or your day-to-day challenges that we are talking about if you have any those kind of challenges that we want to talk or you want to share you you can post your particular concerns there are many experts we have including me many people also give you a response and even there are few experienced people who are not very known but they have experienced that and they can give you that particular answers on your questions and that we that way you can actually don't need to wait for only agile guy just to give you the answer there are many people's where you can collaborate with there are other points that you can talk about our training areas we do many trainings and most of the trainings we do it with virtual we'll talk about few training trainings in a while but you will get notified for our all our upcoming trainings there are expert opinions many times many people they give their articles they talk about what's trending they talk about what you need to go for this particular situation so you will get and connect with an experts within this group secondly we do many webinars and podcasts and talk about what is trending in the market how you can do this particular area how you can collaborate DevOps and agile or many other areas within agile space sometimes we'll do little technical and those are totally free and we get published it within our telegram group so if you are really interested you can join our telegram group and there are many more areas I'll not take much time over here I just want to talk about the we so far have kind of two t6r little more as of March 2020 we are still growing the link is below in the descriptions if you are really interested join here and we will talk about little more about three training trainings that we are doing one is a sprint simulations sprint simulation is anyone who have the knowledge of scrum you have the knowledge of JIRA or rally but you want to have real practical experience so this is the place where you can attend we conduct it with nine member maximum it's a limited seat training totally virtual twelve hours and we conduct it in kind of alternate days you join there you will get the experience of all the event ceremonies the reports we prepared how exactly the scrum works so that's the details if you want to look for I'll just slide into the next one I'll just move back take a look over here I pause your screen and if you're interested you can click on the link below and below I in the descriptions the link is there you can go and look for more details now the next one I am talking about the mastering JIRA this mastering JIRA is if you look into from the introductions to advanced label if you are want to know about JIRA have some ideas but there are some lags this particular training is covering total understanding of working as Gia so not any other part of Atlassian product but JIRA from base to Inter advanced administration where how you can do issues and filters artifacts practices burn down chart reports dashboard administration workflows how you can make workflows how you can customize fields everything we cover in this 16 hours you if you are interested the link is below if you have any queries join our telegram group ask the questions will happy to help if you want to know more about this I am just moving out from the screen for a moment you can take a look and this particular screen what you have is all the course content for all the four days pause it and then you can go for it I talked about the next one this is as we have recently introduced it a 45 hours extensive training to make someone a scrum master who have some idea of business analysis or key way you want to go towards a scrum masters role this is where you can start with we give extensive training on understanding the fundamental of scrum Kanban artifacts their mettle scrum matrix reports different ceremonies everything in details now the next stage we give you an overview of how as a scrum master you should have some idea on JIRA and how JIRA works the third stage where we blame the stage one and stage two and make us simulations of your life project again it's the same simulations but here this is actually something you will start it from the beginning over here what we'll be talking about is you will do the same simulations with just practicing what you have learned from your scrum and Kanban a stage one and then we talked about the zero and finally we talked about the stage 4 will prepare you for getting ready for the interviews we will talk about your resume a and these are all the stages what we have it will help you to prepare your resume a will do mock interviews and those are the all areas and it will be very much ready to go for a scrum master interview these are all the virtual training will talk about the safe certifications a classroom based training that we are start Lee doing in India primarily in Delhi space we are about to start virtual class on safe area as well that will announce soon in our telegram group or in other some videos and we do safe training within this daily area so if anyone within your corporate or if you want to join let's connect and we'll see how we can collaborate together and have the safe training together this is all what I wanted to share in between thank you okay now we'll come back day one that's actually eighth day of your IP tration and these are the different topics we talked about there are multiple topics business contacts product solution and vision architectural vision and development practices these are the content readiness we'll start with our PI planning on day 8 with these three items and then we go into planning context and launch our pl once we'll launch our P I the next activity it's a big activity team breakouts day one that means we have another breakouts our day two this is the first day that team breakout we go into deep dive what exactly we are doing inside the team breakout in a while and once our breakout is done the team creates a draft plan and that gets reviewed and finally the management makes some adjustment and whatever the review they have done we scale as l recommend a typical time frame for each of these activities and those times are like this the first one I can see a business context it start at 8 and end at 9 so 8 to 9 one hour the discussions on business context by your business owners happen and if you look into this diagram you can see that our number line and there is a blue line Amber line is that how much time that particular item will take and before the green line is how much time already spent before this particular event so if I talk about the architectural vision that's in at 11:30 and then we start our planning context and lunch and planning context and lunge that actually 11:30 to 1 that team breakout day one that's three hours of activity and all the team members work on their own team areas to do multiple activities we'll come into that in a while and then finally we will do a draft plan review and management review and problem solving if I talked about what exactly these first three pointers are offers three topics are those are content readiness so business context is something that a senior executive line of business describe the current state of the business and what their upcoming objectives or vision is product solution and vision is product management presents program visions pictures prioritizations then they do talk about different features they have what are the changes they have from the previous p.i planning any milestone they have all they talk about on the product visions and solutions solution and product visions then the architectural visions we talked about system architecture is engineering your system architects and engineers or the CTOs they talk about the present present architectural states they have and if there is any frameworks needs to be developed or any tooling tools there needs to develop any new libraries they need to develop or any integration with existing library then is to work on any changes on the existing functionality in terms of architectures they need to do all those discussions there mentions for the upcoming work keeping in mind the product envisions we have the business context we have the fourth item planning context and lunch this is where the agile release train engineers present how this process of planning will happen in case you are new to the scale agile framework and you attending your scale p.i planning don't worry you're released and engineer will give enough guidance for kind of one and half hour for every team members or all the RT so that it will be easy for you to proceed with the p.i planning once these disk details is done our team breakout starts team breakouts have multiple steps we'll talk about all of those steps in a while but this is something our each agile team they plan their capacity the break down stories from features they load the stories into different iterations they update the load for each iteration they identify dependencies they identify risk and many other activities they do and finally they prepare a draft plan once the draft plan is ready the next step we do is our draft plan review so each agile team they present the draft plan and risk impediments whatever their key planning output is capacity how much the load they have what is the stage objectives a stretch objective is not a right term if we're talking about 5.0 but what are the uncommitted objectives they have they talked about that and they present it to business owner product owner product management stakeholders and any other team members and the last step of day one is adjustments owner because in the previous step the team demonstrated and the business owner stakeholders they have reviewed it and now the it will be time it is the time to make any adjustment in case they feel now let's go into a deep dive of this particular plan all these seven steps we have and what exactly we are doing under each steps let's try to understand that this is yes okay on the eighth day that's the 50% of your PR planning you do on the first day of Pi planning that's actually eighth day of your IP treasurer and this entire PII planning even it is day one or day two is facilitated by your RTE now let's jump into the next area of content readiness or the first three topics that we have mentioned over here the content readiness this is what we talked about content readiness so how the content readiness is actually happened it started at 8:00 a.m. in the morning and goes towards 11:30 so it's kind of three and half hours so three and half hours here three and a half hours and where your senior executive line of business they talk about some briefing on exec aynd of executive briefing business context that's come from the executive briefing from your senior executive your product visions and briefing comes from your product management and the system architects they talk about the architect visions so if I am talking about business briefing or executive briefing they talk about the current state of the business and upcoming objectives your product management talks about program visions prioritize features and you talk about the changes from the previous PA planning meeting milestones everything the product manager talks about and if you talk about our System Architect our system architects talked about any kind of architectural change architectural visions common framework or any tooling libraries structural change on the technical side that all informations system market talked about that is required for the business context what dimension this is this all discussion it seems like very quickly we are doing but it's actually big lengthy discussions and goes for three hours kind of after that the PLT comes in picture and started talking about how we'll be executing the next activities the team breakout sessions and they start talking about okay product owners you have the content authority to make the decisions at user story label and how you will be working on you will be coming with all the features for your sprint and the team will be splitting those stories splitting those features into small spawn stories and whatever is required from your product owner the idea also talked about okay scrum master you have responsibility to facilitate and manage that time box because we have very limited time even it is three hours looks Linde but for you when you are working as a team of seven eight members you have eight features you need to break down into those feature into stories estimate them doing planning poker multiple activities you do and it's not that big so that break down sessions will take multiple activities and it will time taking but time as a scrum master you need to check on the time and also whenever you will be running on the hour the team will be executing their activities as a scrum master you will represent your team's progress join a SOS so is scrum of scrum where we'll be having a checklist and you need to update how your progress is and we talk about this SOS in a while when we'll reach to that state and then Tim will update on the program board then LT also talked about your agile teams that their responsibility is to define user story plan them into iterations and work out for the dependencies with the other team this once this discussion is done even this kind of discussions making everyone understand takes kind of one hour to one and a half hour and once that is done it's time when we can start our team breakout so to talk about the team breakout there are multiple steps within the team breakouts so we'll talk about there kind of seven steps we'll talk about eight steps the step one set up the team area under the capacity for each iteration then step two peak a feature from the product manager that's the step two step three estimate the stories using story points and maybe techniques you can use estimation poker or planning poker the step four load the stories into the iteration then write the p.i objective using clear statement that's what also we need to do identify the uncommitted objectives and finally we'll identify any program risk and dependencies so if we talk about each and every steps under our team breakout so if we talk about each and every steps inside these steps what exactly we are doing within our team breakout session we'll jump into the next slide and where we can see the step 1 set up the team area and enter the capacity for each iteration so if I want to set up my team area this is what each team will be making some areas where they will be having one feature area and some iterations boxes we'll look into that what exactly this container will be containing once will reach to that particular state and there will be also creating some other areas where they we'll be having team P I objectives uncommitted objectives raise dependencies or risk board that they have if they are owning within the team level or the local risks they have and finally each team will be having some kind of these areas so team a have some areas as you can see in the screen the team a have some area for them Team B have similar kind of area for them and team C have similar kind of area so this is the readiness of each team areas so that they can start populating what exactly they needs to be work on before we go into step two in the step one you need to identify your capacity now as you know if what exactly the capacity is ideally we should use our velocity to treat it as our capacity for our upcoming iteration now if you are doing it for the first time you don't have a history you cannot have your velocity then there is a formula prescribed by scale agile that you can use eight points for a two-week iterations for each member now if you have a for an example for two weeks print ideally and so five members team will be having so when I'm talking about member it doesn't include Pio and scrum master so five member teams 8 into 5 is equal to 40 story point will be the capacity for a two-week sprint ideally if you are going for three weeks planed it will be something different maybe you can have 12 points 12 into five it will be somewhere around 60 will be your capacity now there are few areas that subtract one point for every team members vacations day and holiday if anyone is taking some leave or vacations you can subtract that one points and that we will go once this is identified you already had the area of your team so you will be making something like that that all the teams I am assuming that all the team have same five members no one have any vacations so every team members have a capacity of 40 by default and the last iterations that is IP durations we are not planning any capacity for it because we should not plan any work for the hype iteration hype iterations will be for innovations and planning you will do root cause analysis for the entire PA you will do the P I planning for next upcoming P I or next P I now this is what we have done as a step one within our team breakout session now the step two of team breakout sessions it will be peek of the features from the product owner so once you have completed your step one it will be look something like this and this is something we able to see that for each team they will be having capacity equal to 40 load equal to nothing as of now because we have not loaded it anything yet now we'll go into this particular area for each team and where we can see that all the team members just have uploaded their capacity and load for every team and every iterations and the area will be look something like that the next point what we'll be talking about is our pickup the features from the product manager so I know all the product owners and product managers have got some support owners have got some features from their product management or they know what needs to be developed and they will be having some initial stories they have identified for each features so from this diagram I can just assume the black checklist is my features and the yellow one are the different stories under that features and that will be coming to each product owner as each product owner is working with one dedicated scrum team over here so there will be that will assign or the the team will start working on them and the team will then eventually may create few more new stories new enablers or they can remove some stories they can split some stories and they will be working that's the second step we are talking about we still have to do seven step within this breakout session so now within this particular step we are having the stories are broken down from the features as necessary they already have planned and now the next step what we'll be doing is we'll estimate the story points so we in the sense as that each team member will estimate each stories on a Fibonacci series they will give a story points maybe they can use a planning poker and as you can see in this diagram that each team have one or two features it it not necessary you'll be having only one or two you may have three or four or more or you can have ten features as well based on how big the team is and how much you got from a product owner house each features is broken down into how many stories and what's your capacity allows based on that you have these many stories for two features team a have two features Tim B had three features team C have only one features and all the features have some sets of user stories few enablers maybe you can't read those the red one are the enablers and they have given story points to all of them this is your step three the estimations now once we have broken down we in the sense as a team have broken down the stories from the features estimated them now it's time to put it new your iteration so how you will be putting into your iteration I am just like taking an example of team a the feature one and feature two they have these many user stories they will put the stories in priority into first iteration once the load will become close to your capacity they will not put any more stories on that iterations so keeping that in mind if you look into this particular screen that feature one have few stories spill over to iteration two and that's actually not a bad thing so in iterations two they have eight and three form feature one and few other stories from feature two and that way you will be distributing your stories in two different iteration and the same fashion steam be have distributed there are three features into their iterations and team C have distributed their stories of one feature they had and as a whole it will be looks something like this so team a have some distribution timbi have some distribution of the stories and team c distribution of some features now if I talk about the next slide we want to identify that where the feature is ending so each features story is stretching to multiple iterations or maybe completing in one iteration we need to find out the story of each feature is ending at what iteration so for an example feature 3 is ending at iteration 1 point 1 where feature for the last story is actually ending on iteration 1 point 2 and feature 5 the last story's ending at iteration 1 point 3 so I can map F 3 the feature 3 at iteration 1 point 1 F 4 at iteration 1 point 2 and F 5 at iteration 1 point 3 so I can make a program board something like that for Team B I will be having something at if 3 iteration 1 iteration 4 2 & 3 and the same fashions I can have different different features mapped into our program board where all the teams they are just putting their features into different iterations where they are ending so this is a earlier what they have done they have splitted the features into multiple stories and putting the stories where they will be ending and they are having the categories of different features now a program board at the left side we have all the team and at the x-axis at the top we have all the iterations and each team is putting their features where their last story will be ending this is the time in this program board they can start working on that dependencies as well and in the program board there is one important thing we can have are the milestones now each features may have some dependencies with other teams if I am talking about the dependencies for an example these are the different dependencies we have the milestone have some dependencies with team B and that dependency can be resolved somewhere around 1.2 similarly timbi have some dependencies with sorry t may have some dependencies with timbi and that feature f2 wills needs to be a have something completed from team b side at iteration 1.3 and f2 is planned for 1.4 and similarly that dependencies come up so if we look into this particular legends over here you can see and this particular diamond shape is your milestone events all the features have that blue tags and the significant dependencies are in red rectangular box and the red strings are the dependency requiring stories features or other dependencies this is actually how you are mapping your dependencies now once we come into a program board let us try to understand little more about the program board so program board is a this is also we are still under team breakout session and we are just giving some brief of the program but it's a key visual radiators and the sequence of inter team dependencies this radiation radiator shows a sequence of inter team dependent if there are multiple team working they may have some kind of dependencies with each other and it visualize that feature level timelines when which feature will be completing that timelines also visualized and also milestone and key events it also shows along with you there are few other informations you can get from your program board let's take a deep dive on our program board once again so as you can see this is one of the program board where we have multiple dependencies and this is something we highlight in these two particular events and the day one we have team breakout and day two also we have a team breakout in this area we change the dependencies or we change the features from one tration to another or one team to another and from there we can actually have the dependencies updated in our program board and this is the time right okay so let's try to understand these features there are some times if some of the feature is does not have any red string attached what does that mean so in your program what you may have other dependent or cross-functional teams let's assume these are the different team teams we have Galaxy maverick spartan rocker this is a different name of the teams each team is working on multiple features few of them have dependencies few doesn't have their dependencies there are some cross-functional teams also you are working on for an example user experience team or system team and they might be having some kind of dependencies with them right and we have the four iterations and hype iterations and at the list at the last we have our pi/2 now once we have these dependencies we may need to identify there are few milestone events we may have these and those milestone will also have some dependencies with within our team or outside our team that everything can be possible now if we want to understand that ok if there are some features I understand the features will be having dependencies with the interred team or other teams but if the feature doesn't have any strings attached that means you can deliver this feature so if I am just removing the dependent features from here this is all the features we have and these features means these features can be delivered independently no dependencies are there so I'm just trying to go little details on the program board now there can be another scenarios we can have before we go into scenarios let us try to understand what exactly this milestone we are talking about so milestone can be something related to any major releases or trade shows or product announcement delivery from an external supplier or you can have learning milestones there can be multiple activities you can plan it and show it on your program board ok now we'll jump into and another topic where we can see there are multiple multiple features or couple of features have marked some D pendants cease like this so if you see if nine and maybe if eleven yes f9 & f11 they are also having some dependencies but here the dependencies are mapped within the same team program board should not you should not mention the dependencies if it's falls under the same team dependencies is required to be highlighted in program board if the dependencies with other team members within your program so that's what don't show interdependencies within the same team now we'll talk about a few other areas when you are planning some features don't plan for your eye pitter ations hype iterations keep it only for innovations and planning you do inspect and adapt you will do P I planning for next P I all these activities you will be doing for your IP tration you should not be planning I'll talk about three more situations of your P I planning so let us try to understand this is one of your program board within a program board I can see there is a bottleneck one team have lots of dependencies from different different teams and features so this is something when you are doing plan P AI planning or some review you need to adjust this particular area right the another area this board I can see the dependencies on the same iterations this is very risky I either resolve the dependencies for f9 if 2 and f11 the dependent with spot and rocker so you try to have that resolution of the dependency somewhere around iteration one two or three before that so don't if you see so the dependence is coming on the same iterations and some the more risky over here is it's on the last iteration so there are high chances that you will not be able to resolve or complete f9 if 2 or f11 because the dependence the chances of a resolving those dependencies is very low and one more situations I will talk about that over here you can see I am NOT about dependencies but one team is too much overloaded if you look into the team galaxy there are multiple features coming into the team galaxy where Spartan rockers have only one ninja have only one unique honor have only two navikev only two we need to find out if we can distribute the load evenly with all the other teams in that way the chances of better quality and better delivery will be more increased okay this is a deep dive on program board let's jump into our topic that we are talking about this particular area the step 5 of our team breakout where we'll be talking about the p.i objectives so team will start writing the p.i objective based on whatever they have committed or they have planned the commitment has yet not startanim committed they have planned something and based on their plan they created some of the PAI objectives program increment objectives at the team level and those are the details high level statement what the team believed they will be deliver as a in terms of objectives this is API objectives and those PII objectives will be come for every team's and that will go back to the team's area few example of the PII objectives for an example enable customer profiling you may need multiple stories or there can be one feature go directly as your PA objectives it not necessary it's you are the best person to find out can one feature we go directly as it is as a feature or there can be two three features make one objectives you can take the decisions and make your p.i objectives the example a second example what we have is add security for third party signing and then customize farewell to enable out of our domain email so these are the different example once you have these features ready you can look into each team area each team have the different different areas and they have the PII objectives also appeared and their areas now we will talk about the name topic that is identify the uncommitted objectives I know P I objectives we talked about there is new concept schemes in scale 5.0 it's the concept is not new the name is new it's uncommitted objective the same concept earlier was known as stretch objective so stretch objectives we'll talk about little about stage objectives under the P I objectives they mentioned something that ok these are the few objectives those are uncommitted uncommitted in the sense we are not committing it will try based on the different bandwidth and uncertainty resolutions we Mabel to achieve it but don't don't take that as our commitment and so uncommitted objectives things not go always as planned so we are keeping something as uncommitted we want to keep some buffer for us and this is not part of team's commitment so they just give it a try if they have bandwidth and any other possibilities and this actually increase your predictability that if the team is committing for let's assume a 30-story point or maybe hundred story points or twenty business values their chances of meeting those business value is much more higher the work is planned but the outcome is simply not guaranteed that's the p.i objective teams can apply so I am taking guarantee of my committed p.i objectives but I am NOT taking any guarantee for the uncommitted bi objectives so teams can apply uncommitted objectives whenever there is a low confidence in meeting the objectives this can be due to many reasons like dependencies with another team or supplier that cannot be guaranteed then you can think about the team has little to no experience with functionality of this type or you can think about their a large number of critical objectives that the business is depending on and the team is already loaded close to full capacity in those situations we still say ok we are not committing it but based on our capacity we will try and if we can achieve it that will be a bonus for us now uncommitted object is benefit of metered objectives before we go into benefit let's try to understand that you have a capacity don't have uncommitted objectives no more than 10 to 15 percent of your total capacity otherwise people will start misusing the concept of uncommitted objectives similarly the few three benefits that I am talking about are adaptability to change improve quality and economics increase reliability ok step 7 that's the last step of our team breakout sessions where we'll identify any program risk and dependencies so each team they will identify some dependencies they will identify some risk for them and based on whatever they have identified that will be come back to each team area and you can see over here each team have their P I plan the stories are planned the P I business objectives also API objectives are there the uncommitted objectives are there the risk are there the dependencies are there and all of them are actually planned for the team and there's the team area now this is the end of our breakout session the team is ready with their draft plan and it's time to get reviewed that draft plan each team their key planning outputs what we have got so far is plan they have made the plan they identify the capacity they got the load based on how much they have actually committed for every iterations or planned for every iterations they identify few PI objectives they identify potential risk and dependencies this is what each team have identified now who will be reviewing that we have business owners product management other team members stakeholders everyone will review and this entire area or the work we talk it about about a draft plan review and this is the draft plan once our draft plan is done we may need to do some problem solving or to fix that so how we'll be doing this is my draft plan at the first thing I the review is done by my business owners or product management and they identify a few concerns a few challenges they have identified so they may mention ok the scope is we can actually do some changes in the scope or we can change some people from team member one team to another team or any kind of resource not only the human resource um infrastructure resource or any kind of other resource also possible they will talk about the dependencies how we can move the features from one iteration to another iteration to resolve the dependencies and many other areas so this is all those points they will go into a problem solving meeting and finally they will talk about the scope negotiation resolve other problems and planning adjustment this is what will be facilitated by your RTE and that's what we will do at the end in the last point a last topic of our day one now when we were talking about the team breakout session it's a three hour sessions let's assume there are 10 teams working on each team have seven members so 70 peoples are working at different places and how we can actually get a track of everyone is going on right directions or somewhere some teams need some help how we can expedite someone is doing little slope so for that scale as I will prescribed a concept called SOS during your it P I planning when the team breakout is happening so we have a checklist SOS is scrum of scrum where and a certain frequency every 20 minutes or 30 minutes all the team members will come to RT or RT will call all the team members to one place where we have a big screen with this checklist and each scrum master will update their states whether their team have identified the capacity for each iteration in the planning or their team have identify most of the stories break down and put into the first two iterations or first first all the iterations all those checklist can be possible so when I'm talking about first two iterations it at least you will give you the idea that it's coming for the first two iterations and you can have first three iterations or first for iteration based on how we want to have your SOS done so as they are te this will be the checklist and this scrum master will come in first twenty second twenty minutes they will update how they are and then after twenty minutes they will come back and put some of the other checks then again after twenty minutes they will come and update something else and that way this chart will keep on updated as they are T prospective they can take a understanding okay a team B is much more behind they are not able to do in proper pace so maybe the RT will go to the team B sides and try to find out if there is some help they need or any area they got start and take that in the further to help the teams okay now it's time to talk about the day two we are done with our day of day one we have our draft plan ready reviewed management have made some recommendations now the first thing on ninth day of your IP duration or second day of your PI planning is planning adjustment these are the quick timeline you can have a quick look on all these timelines you starts at 8:00 and finally when it is ending I will talk about that why we don't have the end time as of now but if these are the states we have planning adjustment team break out number two it's an two hours today means on the day to final plan review and launch then we do a program risk then we have a PI confidence boat then we plan rework if required and then planning the retrospective so the second last a plan rework if required I don't know how much rework is needed so what we will be doing is we'll keep it open we'll start it somewhere - 2 p.m. maybe 2:30 p.m. will be I think the right one I typed it wrong but from there it will be starting and then from there it will be you will start it at 2:15 and based on how much time it needs to do all your rework you will do that and finally we will go for a retrospective once everything is come all commitment is done we will do a planning retrospective it's not iteration retrospective or a program retrospective is the planning retrospective and we'll come into that so let's try to understand the first step eight to nine am planning adjustments what exactly we are doing the address adjustment made by business owner product management stakeholder changes in planning scope then the breakout to the agile teams continue planning with yesterday's agenda and do the necessary adjustment provided at the team level p.i objectives and business owner provide the business value this is what we'll be having as a second step the third step 11 a.m. to 1 p.m. we'll talk about all a gel teams present to the group about their plan risk and impediments no atom to resolutions cuz so we are not making resolution of the risk we are just identifying it the customer accept the plan or the end-user your stakeholders or business owner will accept the plan and finally the agile team will present the p.i objectives it's to all the stakeholders and also what are the risk they identified for program that will also get updated by your RT now program risk this is what your RT will be uploading into the roaming board and the program board or the roaming board will be ready for the entire P I once this is done we'll go for a confidence vote to check if everyone is agreed or have that high confidence or low confidence or they don't have any confidence and based on that we'll decide whether we need to rework or not if we need to rework they will make the necessary changes and again check if that is okay with everyone then we'll jump into the retrospective state so let us try to understand the planning adjustment how we start with so planning adjustment is actually your product management team they comes and talk about based on the yesterday what we have done the review and based on our findings we'll talk about some changes our product owner will advise some changes to make on the scope people and resource it's a one-hour activity so it will be very detailed for each team members so that they can get to know what exactly the changes they need to do once this adjustment is announced then each team will go for another level of another round or breakout for the day - it's a team breakout - where they will start working on making the adjustments so team continues plan based on the agenda from the previous day and making the appropriate adjustment once the adjustment is done they may work for changing on the p.i objective because they have change in the scope they have changed on features resources and the objectives will also be required to change they may remove few objectives - uncommitted they will add new objectives and each team will be having those kind of changes on the objectives one of the objectives is there the business owner will start giving values to each team the business owner will go to each team areas and start giving business values to all the objectives even it is uncommitted objectives or plain objectives the business values will be cause for all of them once our business values is given the adjustment or the objectives is there it will be updated in all the team all the team's area where they have the business value so if you can look into these particular objectives you can see all the objectives have some business values and the objective also a plan and different levels few of new items view goes into your uncommitted objectives now the next step once we have done the plan review and launch that's the final and big event these are the force five steps we have presenting the plan risk and we'll identify risk and impediments then we'll take a concent of the business owner how confident they are and then finally the team will present the PII objectives and if there there is any concern still the business ownership they will make that adjustment so to understand this steps let's try to look into this particular five steps activity as you can see we have these five states mentioned presenting the plan what exactly each team does team a for an example they will present their plan ok this is what their plan is Team B will present ok this is our final plan and this is their presenting to the all audience so team C is also presenting all their activities all their all their plan to the intr audience now we also need to present the next item risk and impediments so each team after just after showing their plan they will be show their risk as well so it's not that team a will show their plan team B will show their plan and Kim C will show their plan and then again team a will show their risk it's not like that team a will show their plan and then team a will show their identified risk then team b will show their plan then team b will show their identified risk and team C will show their plan and their identified risk in that way all the team members sorry all the teams will show their risk to the entire audience at the same time when the team creates the risk few of the risk are local to the team view of the risk may be program label risk all those program level risk will be collected by RT e and that will later move into the program level risk board or the roaming bear board we'll come to that once we'll reach to that state now once this is done the next step we will talk about the taking business owner confidence as of now we have planned it we reviewed it we made at we replant and finally we are presenting the risk and plan what we have but we need to get the confidence or the consent of our business owner so the team is actually asking to the business owner is it acceptable team a is asking team b is asking team C is asking by showing okay this is what the plan they have and based on their planning that question asked from every team and finally they will get a consent okay if it is ready or not the fourth step and the final plan review and lunch is presenting the P I objectives so each team they will be presenting okay this is the P I objectives we have and Team B will say this is the P objective and business value we have and finally if there is any adjustment required on that same step based on the objectives they have mentioned the business owner will mention okay the business owner have some concern the team will make some adjustment and show that to the intr audience once again if the business owner still have some concern it will go on that loop until business owner is very much confident what exactly we have done this is so far we have done under our final plan review and lunch now we will talk about the program risk each team have some risk identified and few of the risk again Isis can be a local risk few of the risk can be your program level risk so your stake your RT will pick one by one risk from each team areas and if it is a program risk we will talk about or ask to the entire team members or whoever is responsible that if anyone wants to own it or anyone help mitigate it or in do things this is the CC issue is resolved or this risk is resolved or we'll accept it as it is so based on the final information received by RT that risk will go into the particular area of the roaming board roaming board is resolved own accepted and meeting we'll talk about those in a while and similarly in the same fashion all these program label risk will go into different quadrant of our roaming board now what is resolve what is own what is accepted and what is mitigated let us try to look into this resolved the teams agree that the risk is no longer a concern own someone on the train takes ownership of the risk since it cannot be resolved during PI planning accepted some risk are just facts or potential problems that must be understood and accepted mitigated teams identify a plan to reduce the impact of the risk so that's the roaming risk right the next topic will talk about the PI confidence vote as we already talked about dependency resolved risk where addressed and now we test it's a time to take a confidence from everyone that everyone have the same confidence of this particular planning we have and that if that we have low confidence will see we will see that as a rejections if it's a high confidence we'll take that as an acceptance if it is a rejections then we that may go and get escalated and a corrective actions may require we may need to adjust the plan how will identify the vote or confidence from everyone that the technique is called fist of five so fist of five everyone is shows finger one is no confidence to ease little confidence and five is very high confidence and based on the majorities of those fingers from maturity of the people we can identify what's the current state of our planning if it is one or two finger that means team will rework on the plan if it is three four or five then we think okay it's a moderate or high confidence the team has and the management should accept that commitment so we need to get the confidence of all involved parties so that we can proceed with that one more important information that if we have one or two vorse then any person voting less than three can get an opportunity to raise their concern may add few points to our roaming board sometimes we may need to change our planning or we may need to add some risk in our risk board because of their low confidence of some potential risk we have next step once we have done our confidence vote we may need to do some adjustment based on the low confidence we have received so if required team continuously or working on the plan until a good confidence fort and they will do that for some times and hopefully after some times we'll get a good confidence board and then planning retrospective once our this particular all the activities are done the last step what we have is P AI planning retrospectives sopia it's not a retrospective for any program level activities or iteration level activities is this the planning retrospective we are doing we will talk about what went well what did not go well and how we can do better so that you not talking about the process of doing retrospective now but I believe everyone you understand how retrospective happens and the same way will be do your retrospection x' everyone will put some pointers to different items and the next action items or improvement areas that we'll be working on our upcoming p i-- or the next P I let us try to understand once or p.i planning is done what we'll be doing so each team have their own p i objectives team one team two team three and team for they have different different p i objectives as a team level so RT and art stakeholders take all those p i objectives and then summarize those objectives into a program level objectives the program level objectives will come from each team and those program level objectives is shared among all the teams so each team they for the iteration they have iteration goal for p i level they have team p i objectives as a whole art they have a common program p.i objectives and that they will be working on and these p.i objectives later will contribute to your roadmap and also help improve the forecast for the upcoming two or three pies and that actually taken by your product management's to update your roadmap okay after p.i planning you will have your program board ready which will help tracking dependencies during scrum of scrums events that will also help you and maintain or manually or throughout your ALM tools you can have that your program board and that needs to be maintained based on how we are progressing if the dependencies resolving new dependencies arise you will be maintaining it can be maintained by on your LM tool or it can be maintained manually if you are managing a physical board so once your PA training is done each team will get some details of pre-populated iteration backlog for the upcoming PI the team P is objective they will get iteration plan and the risk and that will get by all teams if there is some program risk that will be with your RT so this is what each team will take with them from the PI planning each team will take a pre-populated iteration backlog for the upcoming PR the team will take their P I objectives team will take the iteration plan the thing will take the risk the program risk again RT will take it now after the P I planning the team will go back to their own area of executions and they will do a iteration planning for the first iteration based on whatever they have planned they just need to give a mmm another fine tune on the iteration label planning and they will start executing that first iteration now let's talk about if you have more than one train in your scale agile framework so for an example you have 300 people you may not able to manage it 8:1 art so you may need two or three yards and if you have more than the one art you need to have a solution layer a large solution layer where one solution train will be there which within one solution train there will be multiple art or agile release train so if this is where we are doing the P I planning at art level and in a solution train if I look for a solution train one solution train within the solution train will be having these many three arts and also you can include supplier also as a part of your solution now if you are doing eighth and ninth day as a art label P I planning we need to do some pre P I planning at a solution level and that we do on the sixth day of IP iteration that's prepare planning and after the iteration all the pipelining is done from the art level at solution level we do a post P I planning and if you look into the framework the large big picture you can see at the solution level the vertical bar you have four PA training you have pre and post for your solution layer ok let's try to understand this one again what we do in the PPR planning in the solution train in the solution train prepare for agile release train supplier and provide and coordinate inputs about objectives milestone business context solution contexts that you do as a pre PA context on a solution train now after that we start on eighth and ninth day for our actual PI planning at the team sorry at art level once the art level PA training is done the second half of day 10 or the last day of the IPT raishin will do a post P I planning so we follow-up for agile release train or supplier integrate the result of art planning into visions roadmap solution level PA objectives and all those we work on so what exactly we do in this solution train pre and post Pai planning it supports and coordinate the various arts in the solution the planning at higher level the solution development alignments then we talk about provide directions and visibility into their trends and there are a few other advantages we have let's say you can if you want to read you can just pause here and read that I'll just go ahead and talk about pre and post P I planning what the inputs and outputs we have so if you talk about inputs for pre and post P AI planning inputs we can have solution roadmap we can have vision we can have solution intent we can have capabilities we can have solution enablers these are all come as a input for your solution train P I planning or pre PA planning and post PA planning what is the output of pre and post peer planning you can have a smart solution PA objective in the arc level we had P I objective those all PA objectives are smart I am NOT repeating the acronym of smart right now but you will get those PA objectives at a solution level then you can also get a solution board we had a program board at arc level you will get a solution board we'll talk about how the solution board is looks like and then we get a confidence vote of solution P I objective at the solution we will talk about who are the participants so that you can actually find out who give those confidence vote at the solution level then context for solution demo so a solution Planning Board highlight so what is the solution board a solution Planning Board highlight the cap abilities anticipated delivery dates and any other relevant milestones for the solution who participates on pre and post P I planning's if I talk about participation solution stakeholders solution train engineers or ste in program level we had Artie at solution level we have a ste solution management the in program level we had program management here we have solution management solution architect solution system team management then representative from all art and suppliers from program labels they also participate if we look into a quick overview on what are the steps we do on the pre P I planning this is what we do in pre PR planning we do a P I summary report then it's actually started a 201 30 we talk about business context and solution report solution backlog and next P I features what they will be working on because that features will be actually going to your program level as a feature backlog if I talk about the post P I planning that's also again in solution that's happened on the 10th day of hype literation x' over there will be talking about making some p i planning report what all the Tal the art label have done they will launch the solution and then they will review solution level plan discussion on risk identified at individual art and solution level context and if necessary team revise the plan may need follow-up meetings with retrospective us and finally the planning retrospective and moving they will do some planning and retrospective for the solution label pre and post planning and move forward output of pre and post p AI planning smart solution p i objectives I am NOT going into the details we will talk about the solution program board and the solution commitment that you will be getting if you want to have a quick look in the solution board this is how a solution board will looks like we had a program board after P I planning at a program level for each arc over here we have multiple art art one r2 and r3 each order solution label they have different capabilities and they may have some enablers and in your the same if the board will looks like same instead of features over here or instead of team you will be having the art and the iteration will be remain same you will still have milestone at solution level you will still have dependencies between a1 capabilities to another art you can have the inter art Dependencies mapping with capabilities p i objectives are at different levels we will talk about if we are having the p i objectives at we have two different team sorry two different train each train have four 14 so each team have their own PII objectives now at team levels if we come into program level each program at one p i-- p i planning they have one p i level objectives so if i have to train I'll be having to pee i objectives those two p i objects will combine with two one solutions and that will become our solution objectives and that's way the p all those p i objectives from team to program to solution is actually get rolled up and everyone get their local context solution get their local solution level context program gets their local program level context and team definitely they have defined their p i objectives so they have their own objectives okay so this is in the last slide where we'll talk about the business benefit of p i planning so i just read it out you can also pause the screen and read it the first one is established face-to-face communication across all team members and stakeholders building the social network the art depends upon aligning development to business goal with the business context visions and team and program p i objectives identifying dependencies and fostering cross team and cross our collaboration providing the opportunity for just in just the right amount of architecture and lean user experience guidance so we don't make the entire architecture for the program we just make the architecture as much as required for that particular scope maybe to be a maximum or 3p i matting demand to capacity and eliminating excess work in progress and the first decision-making is also there that's all from my side for the scale agile another video this time I have planned for peer planning I bring up more videos on some other part of scale agile till the time stay tuned if you like this video subscribe and hit the bell icon so that I will get to identify that you are actually get helpful from this video and that will also motivate it for me in that time have a wonderful day bye bye

Channel: Agile Digest

Views: 75,378

Keywords: Agile Digest, SAFe, Scaled Agile, PI Planning, SAFe Program Increment, SAFe PI Planning, Program Increment, Scaled Agile Framework

Id: u3ixs6GS6HA

Length: 86min 54sec (5214 seconds)

Published: Sat Apr 04 2020