The below article is adapted from our recent PI Planning webinar.
PI Planning is a core mechanic within SAFe; it’s one of the few things that SAFe does that is unique to it amongst all the other scaling frameworks. This series of articles explores how to approach PI Planning in a way that preserves agility and empowers the teams.
The first article covered Principles and Preparation which provide the intent…
Planning
…that drives PI planning.
Concrete examples of the Standard Agenda for PI Planning exist in the SAFe Training material, rather than replicate existing material the diagram below provides an alternative visualisation of the planning processing using a W shape
Figure 1: W Visualisation of PI Planning Agenda
The red horizontals represent the different levels of the framework and therefore the focus of the activities that take place.
- Portfolio level at the top represents the bigger, wider reaching, longer term concerns of the large organisation.
- Agile Release Train through the middle, catching the mid-peak of the W, representing the concerns of this team-of-agile teams with a focus on this Planning Increment.
- Team level across the bottom focusing on the cocerns of individual teams.
It starts out on Day 1 with the corporate level context, which is a portfolio concern. Where is the organisation trying to get to, the bigger picture, the longer term. Then we bring the horizons in to this Agile Release Train, this timebox; what is this Agile Release Train trying to achieve. Whilst the focus is on planning the next PI, it is necessary to have a little bit of a look-ahead on the roadmap in case any dates or work in the future have an impact on the PI being planned.
Architecture, and by extension Architecture encompasses Regulatory, Compliance, Security, UI/UX or any other centralised specialisations that might apply in your context, Architecture is a first class citizen. They get to present the technical challenges that need to be addressed in this PI: architecture and infrastructure, tooling and processes.
Briefings done, team breakouts. The focus here is the teams building a plan to get themselves through the next PI, but because all the teams are planning in parallel at the same time if a team does need help or assistance then they can collaborate with each other to resolve the challenges and factor them into each team’s plans.
End of Day 1 everyone gets back together again as the Agile Release Train, the peak in the middle of the W. At the draft plan review teams present to each other their progress so far. Given that insight the central roles can then conduct the Management Review, the results of which can be communicated back to the teams at the beginning of Day 2.
Back to team level and the second breakout session. More of the same but factoring in any advice that developed overnight. Towards the middle of Day 2 everyone comes back together as the Agile Release Train for the closing activities: Final Plan Review, Risks, Commitment, and Retrospective. After the event the commitment can be communicated up to management and across to other Agile Release Trains, up and across means that it’s a Portfolio concern.
Distributed and dispersed planning events the W gets spread out over more and more days as the amount of time available where the time zones overlap becomes smaller. Ultimately it is still about 16 hours of process end-to-end but spread out over more, but shorter, days.
For Large Solutions the W gets stretched upwards. There may need to be briefings for the Solution Train as a whole, before briefings for an individual ART within the Solution Train. After the Management Review there will be a Solution Train Management review to identify and highlight challenges across the trains.
Briefings
Remember your audience, communicate to them and communicate what they need to know.
For every feature being presented only one team in the whole of the train is going to pick it, only that team needs to know the details, therefore presenting those details is a waste of all the other teams time.
Keep it to:
- What Is It
- Why Is It Important
- Who to talk to for details
If you haven’t yet pivoted to stream aligned teams, then maybe highlight who you think might need to collaborate to get the value requested delivered, but don’t dictate, don’t break autonomy.
Communicate what needs to be communicated efficiently and effectively and you get more time for…
Breakout – Teams Pull from the backlog
…the breakout sessions, where the real work is done.
Figure 2: ART Backlog Goes Up On The Wall
The features go up on the wall. Typically highest priority at the top, lowest towards the bottom.
If you need a ladder, and have to have attended the relevant health and SAFety courses for working at height, just to reach the top of the list then maybe you’ve got the granularity of your Features wrong… physical visualisation is a wonderful thing!
Historically, for an in person event, we would have put a small (3”x3” / 75x75mm) Post-It on top of a large Post-It (8”x6” / 200x150mm). The smaller Post-It is used as a token, it is taken from the wall to indicate that the teams are planning it and gets transferred to the ART Planning Board once it has been planned. The larger Post-It provides space for teams to write their name in so that we know which team is taking the lead on the Feature. The Product Manager typically writes the Post-Its because they can read their own handwriting and they’ll remember to write other important bits of information such as references into the Backlog Management tooling.
Figure 3: A Team Pulls A Feature From The Backlog
Someone from the team, often it’s the Product Owner but it could be anyone from the team, goes up and “pulls” a Feature from the prioritised set. Remember Lean step 4: “Let the customer pull value from the producer”, this is that step in action. The customer, which in this instance is a team, is pulling value, the Feature, from the producer, the Business as represented by the Product Management Group that produced the backlog. The pull mechanic balances demand, the backlog, against supply, the capacity of the teams. It also helps preserve autonomy because it allows the teams choice over which Feature they pull.
Which Feature should the team take?
|
Teams are advised to take the highest priority available feature, but they are empowered to take any feature from the wall. |
They might not be able to take the highest priority available feature because it’s not their area of expertise and it might make more sense for the team who are experts at it to pull it.
They might not be able to take the highest priority available feature because they don’t have enough capacity to complete the feature. It’s better to find something that can be completed rather than have a feature incomplete at the PI Boundary where it has the potential to become waste if the remainder isn’t prioritised in the next PI.
Teams Are Only Allowed To Take From The Wall
What the team isn’t allowed to do is to go off into the depths of the backlog to find something to keep them busy.
| “Found it, this is our Feature, Feature 99 in the priority list!” |
When does the organisation need Feature 99? Not anytime soon, certainly not in this PI, otherwise it would have been on the wall!
Beware The Utilisation Trap
If there is nothing that the team can take then they just have to take something and learn how to do it. The advantage is that next time around the team will have a greater breadth of experience and can take from more of the backlog. Keep this up long enough and complex sub-system teams slowly evolve towards being more stream orientated as they continuously learn… isn’t that a core competency or something…
“But wait,” cry the management “if we give the inexperienced team that feature it will take them twice as long to get it done as it would the expert team!” Yes the expert team would complete the feature quicker, but what if they’ve already got months of work queued up in front of them, you’ll still get the value quicker even if it takes the inexperienced team twice as long to do it because they can do it now. Think cost of delay rather than maximum utilisation!
Don’t invent work to keep a team busy, that’s waste. If the team doing the wasteful, invented work need help from other teams, then that’s imposing wasteful work on other teams who might be trying to real work. Waste squared. The wasteful work starts inhibiting value delivery!
Teams Create Stories
The Product Owner having helped elaborate the business need in the Feature can explain what that need is to the team; at worst they know who the expert is and can grab them and drag the across the room to explain the detail to the team.
Figure 4: The Team Creates Stories To Realise The Feature
The team creates a set of stories to solve the business challenge posed by the Feature. This is Story genesis, story creation, starting to form a new team backlog for the next 10-12 weeks.
Don’t expect perfection
The stories don’t need to be perfect, a couple of words is often enough. The teams still have Backlog Refinement and Iteration Planning to get the stories into the perfect form for execution, properly worded in User Voice Format, with well formed acceptance criteria on the back. For the purposes of planning all that’s needed is enough detail to allow the team to estimate. The estimate is used to reserve space in the forthcoming iterations to make sure that the team aren’t over-committing, that they aren’t taking on too much work.
This is where the challenges lie, teams often forget that they’re “planning to solve the problems in execution” and instead “try to solve the problems in planning.” There is 8hours of team breakout time for planning, not enough to solve all the problems posed in the features, there’s 8 weeks of execution in which to solve the problems. Why do some teams feel the need to ensure that they have an absolutely perfect plan? It’s probably history at fault…
I always say that estimation has two parts to it, knowledge of the work item being estimated but also knowledge about ourselves as a team, that we have the skills and expertise to solve these problems in the future. Many teams lack confidence in their own abilities to get things delivered as a team and they try to compensate by putting more and more detail into the work item being estimated, often to the extent where they’ve solved the work item up front in order to produce that estimate. All that work to get a perfect estimate is likely to be outside of any formal planning and governance mechanisms and will impact the teams predictability and deliverables, and the estimates produced are often used for do or don’t decisions about the piece of work; providing a solution and perfect estimate for a piece of work that you then decide not to do is waste. The real fix is not more detail around the work but to upskill the team so that they do have the confidence that they can solve the problems they’re estimating without necessarily having all the detail present about how the problem will be solved.
In the old world if the estimates were wrong and the plan was compromised then the wrath of the Project Managers would rain down from on high. Woe betide the software engineer that got their estimates wrong due to insufficient data. The old world’s lack of psychological SAFety drove the wrong behaviours, but just because we’ve said we’re Agile and we’re doing Agile Processes doesn’t mean that the behaviours have changed yet, old behaviours die hard.
We don’t need a perfect plan, we need enough to ensure that we’re taking on the right amount of work, and that we’ve found all the collaborations, the dependencies, between the teams.
Colour Coding
Welcome to the agile arts and crafts project…
We can use colours to represent different categories of work: business value, exploration, infrastructure, risks and issues. The actual colours you choose is somewhat irrelevant and mostly dependent upon the colour of Post-Its that you have access to. What’s important is that you do have colour.
Standing at the front of a big room, or on a digital whiteboard zoomed right out to see everything, it’s impossible to read the Post-It’s but their colour is visibile.
In the western world red is the warning colour, red is risks, red is errors, that team, that team over there, they have all the red Post-It’s. Why? Maybe I should go over and find out what’s going on.
Figure 5: Colour Coding Helps Visualise The Work
For the central roles of Product Management, System Architect, Release Train engineer and stakeholders, business owners, the colours are a visible trigger to go and have a conversation. It’s good to talk, get the problems off your chest.
Objectives
Sources
Now we can turn our attention to objectives, as the work is planned out it gets described in objectives.
High level, human readable statements of where our teams time and effort is going to be spent.
Objectives are not just a translation of the features, they describe everything the team intends to spend it’s time on and teams do more than just deliver features. So, what are the sources of objectives?
I would suggest:
- Features make good objectives, but it’s not just !a feature becomes objective! because features are negotiated during PI planning, the scope may change, make that transparent in your objectives. Large features might be deliverable incrementally, we could express each of these increments as an objective in it’s own right, think MVP experiments and risk mitigation.
- Helping another team to deliver a feature makes a good objective and the teams that you’re delivering to should be listening out to see whether you’re delivering to them what they need.
- Internal Work that the team know they need to do to keep the lights on, to keep the world turning, but they have to be transparent about this, so turn it into objectives to make it visible. Teams should always be empowered to put their own internal work into their backlogs and plans.
- Capacity allocations are used to deal with the known unknowns. Support, defects, incident handling, we know it’s going to happen, it we don’t know what it will be until the phone rings and… oh. But because we know it happens we can set time aside, reserve capacity. Honouring our core value of transparency we need to make it visible that this has happened, not least because whoever’s managing the defects is going to want to know that capacity has been put aside.
SMART
Specific, Measurable, Achievable, Realistic and Timebound.
The default time-bounds for an objective is the PI; don’t constrain yourself unnecessarily, give yourself the ability to move things around during execution, but if you do need to constrain something tighter, say collaborations or explicit deadlines, then do so. I prefer to use the name of the milestone than an explicit date, or an iteration number, since the name of the milestone means more to humans than a date.
| Further Reading |
|---|
| Objectives are another deep topic that gets very little slide time in the trainings, which is worrying since it’s objectives that we commit to and if they’re badly formed then the commitment is badly formed. SAFe Fellows Ian Spence and Brian Tucker have written a series of blog posts on Objectives: |
Planning Board
Once the stories for a Feature have been created, estimated and allocated to their candidate iterations then the ticket for the Feature can be transferred to the other output from the PI planning event, the ART Planning Board.
Figure 6: Feature Transferred To ART Planning Board
There are columns for each plan-able iteration, typically smaller columns on the right for the Innovation and Planning Iteration and the Next Planning Interval. Work isn’t expected to be planned into the last two columns, but they are needed to visualise any key dates that need to be planned towards. Just imagine that a release is scheduled for the beginning of the next PI; when is the work for that release going to be done? In the next PI? No, in this one! That look-ahead that the Next Planning Interval column provides is necessary to be able to allow the teams to answer the question “is there anything we need to do now to support the future?”
There are rows for each team, typically rows on the bottom for shared services such as architecture, security, ux, rows for other release trains that you collaborate with regularly and a row for any external dependencies.
Once a team understands when they think they can get a feature delivered then the feature ticket is transferred to the Planning Board in the iteration where they anticipate delivery to occur.
Collaborations
| Dependencies | |
|---|---|
|
Dependencies, oh how I hate the word. Dependency implies helplessness and within the release train we’re not helpless, we are a team of agile teams, we work together, we collaborate! Although if you are taking a SAFe exam after this it will be referred to as dependencies since you are helpless in an exam situation.
You have to be careful with words, they have power you know! |
How do we handle collaborations between teams?
| The first rule of Planning Boards is “you are only allowed to put tickets into your row.” If you have a collaboration with another team the first thing to do is negotiate with that team to get what you need from them represented in their backlog. They can then summarise whatever they’re doing for you in a pink ticket and put it up on the Planning Board in the iteration where they intend to honour the collaboration. |
The stickies can the be linked together with string. Agile arts and crafts again… electronic string is available for those existing in the digital realm. The one thing that I haven’t been able to replicate in the digital realm is the embarrassment of having airport security confiscate my scissors, again…
The string represents the collaboration, a collaboration that has been identified by the teams and that will ultimately be realised by the teams. To steal a quote from Henrik Kniberg, “a centralised tool for visualising decentralised collaborations and delivery”, built by the teams for the teams.
Any critic that thinks this is an imposition hasn’t understood how it can and should be done.
| Further Reading |
|---|
| The Planning Board is a hugely powerful visualisation tool, it doesn’t just show anticipated value delivery and collaborations you can also see deficiencies in your organisational structure as well. Brian Tucker has written a series of articles on the Planning Board: |
The team can go back and pull more features until they’ve filled their capacity. Other teams are pulling features and negotiating until they’ve filled their capacity.
Presentations
Read the objectives.
Just read them.
They should be an accurate representation of where your teams time and effort is going to be spent.
If you feel that you need to explain the objectives beyond what was written then maybe the objectives weren’t well written.
Experience is that engineers have a tendency to tokenise the objectives, to condense them into as few words as possible rather than them being a human readable statement. Remember the audience, they don’t care about all the internal problems that the team has had to solve, they want to hear about outwards delivery of value, where the team is helping them, the very things that should be expressed in objectives.
Experience with managers, and some agile coaches, is that they make the objectives too aspirational, too high level, “this team intends to save the world!”, can they really do that on their own?
Objectives are statements of where the team intends to put it’s time and effort.
Everyone listens, everyone. Is this team delivering to you what you need?
If you represent the business, is the team delivering what the business needs?
If you are a team member in another team, are they delivering to you what you and your team needs?
If the answer is no then that’s a trigger for conversations with that team in the next breakout.
Management Review
A little structure goes a long way.
You can’t and shouldn’t try to pre-empt the conversations in the management review because anything could happen in the next half hour, but some structure can help to drive the conversations towards conclusions.
I would start at the ART Backlog and the question being asked here is “have the right features been taken?” This is where you need to know the available capacity from the draft plan review; we’re asking that not to check that teams have planned up to their capacity, we trust them to be sensible and leave a little spare, we want to know what capacity is left. If we’re looking at the backlog and there are half the features left on the wall and the teams have told us that there is half the capacity left then it’s a reasonable assumption that most of those features are going to end up in that free capacity on day 2 of planning. But, if the teams have said that there’s only a small amount of capacity left and there are still half the features left on the wall then some tough decision have to be made; have the right features been taken? Which features should claim the little capacity that’s left?
Here begins the facilitation challenge, it’s very easy for the management to lapse into command and control behaviour: “You, yes you laddie, that’s your feature, get it into the plan…” Are you feeling empowered? Lose that empowerment, that autonomy, and PI Planning quickly becomes the old world of telling people what to do, just with some new agile buzzwords added. Instead, all the advice needs to be posed as problems, challenges to solve, the top-right quadrant from the earlier alignment and autonomy diagram. If anyone is worried that the teams won’t solve the problems, remind them that at final plan review tomorrow they can always reject the plan if the teams haven’t solved the challenges presented.
From the backlog it’s usually a short stroll, or a scroll in the digital world, across to the Planning Board. The question here is are the features coming out in the right sequence. The visualisation allows you to see bottlenecks, challenging dependency chains, are the teams planning towards the key dates. Structural issues also appear here, complex sub-system teams will appear as lines of pink collaborations on the Planning Board, are they a bottleneck?
Third step is to tour the teams themselves. This is not being done to critique the plans, if people want to get involved in the plan detail do that in the breakout sessions. The tour is to look at the risks; at this stage risks can go three ways.
- Team level risk: will be politely reflected back into the team and they can build a plan that deals with it.
- Missing information: the central roles with their knowledge and contacts might be able to get that information back to the team for the 2nd breakout on day 2, the team can incorporate that information into the plan and de-risk the situation.
- ART level risks the team should be encouraged bring these up at the relevant point in the agenda on day 2.
That little bit of structure, ART Backlog, Planning Board then Risks, is often enough to drive the conversations towards conclusions.
Who’s involved? Who are “the management”? The central roles for the Agile Release Train, the Product Manager, System Architect and Release Train Engineer. Also the stakeholders, the business owners. Then there is a recommendation that at least one representative from each team be present to provide team level details and to relay any team specific advice straight back to the team that doesn’t need broadcasting to the whole train.
| Further Reading |
|---|
| There is a series of articles detailing IJI’s approach to the Management Reviews along with stories of some of the challenges that have been encountered over the years in the Management Review. |
Scoring
From a team perspective the team breakouts on Day 2 are much the same as Day 1.
There is one additional activity that happens on Day 2: The Business Owners are asked to get out amongst the teams and score the Objectives.
There are three reasons for doing this:
It acts as a forcing function to get stakeholders to engage with the objectives and understand those objectives. What we don’t want is to get the end of planning and be in the final plan reviews and have a stakeholder turn around and say “What on earth is this? what are you doing?” and to then spend time explaining to the stakeholder what’s going on, whilst the entire ART, all 100 people, are sat around watching! Not a useful use of everyone’s time, so have those conversations in the breakouts team directly with stakeholder.
The number acts as a Data point for the team to help with team level prioritisation. The team are always in control of how they sequence things in their backlog, this is just an input, but when bad things happen, and they will, and the team has to prioritize and decide what to focus on, the score let’s the team know which objectives the business considers most important. Because the objectives are a super-set, it’s all the other things that the team does over and above just the features, it allows the business to rank those other things, support, maintenance, local work, can be positioned relative to the features.
Finally these numbers will be used to close the loop at the end of the Planning Interval. Because the most important objectives get the higher number, the closing will naturally be weighted towards the most important objectives.
More detail and experiences in the Objectives blog.
Risks
This article isn’t going to cover the whole ROAMing process, that’s already in the training material but what should be discussed is ownership.
How do you determine ownership?
Once a risk has been identified as needing to be owned I would ask the train:
| “Can anyone volunteer to take ownership of this risk?” |
That act, of volunteering, of pulling the risk towards them, is hugely important. It’s them psychologically taking ownership of the risk. Push a risk onto someone and they’re more likely to reject it, to ignore it, and we don’t want that. We want the risks to be properly owned and for people to be actively managing them.
What if nobody volunteers? Well the default owner becomes the Release Train Engineer, not that they have to manage the risk but they have to work out who should own it and politely encourage them to volunteer.
Given that these are Train level risks and above it’s a high likelihood that it will need Train level people or above to own these risks!
Commitment
Do the teams think they can deliver this plan?
The commitment they’re being asked to make is in two parts, and even Agile Release Trains that are many Planning Intervals into their journey I always remind them of the commitment that they are making. Firstly they agree to deliver the objectives that they have just set for themselves through the planning process but in the event that facts show that an objective is not achievable then teams agree to escalate immediately. The escape clause is pure transparency, don’t hide the bad news, get it out in the open so that the bigger team of teams, the Agile Release Train, can try to deal with it before it escapes outside the agile release train.
Always advise the teams to build a plan that they can commit to; there’s no point deliberately sending yourself around the replanning loop. Most engineers are fairly sensible and work out pretty quickly that that’s the easiest course of action.
In terms of practicalities; go team by team asking them for their confidence in their part of the plan and they have to do this based on the assumption that the rest of the train is going to vote with reasonable confidence. Then the Agile Release Train as a whole, everyone, including all the central roles and stakeholders. The commitment is as much the central roles to the teams as it is the teams to the central roles.
Commitment has been gained. When was the last time that there was commitment to a plan from the people expected to enact the plan? That’s possibly worth a celebration.
The plan will elvove, it can’t and shouldn’t be carved in stone. By committing to the high level objectives the detail underneath can remain Agile, the stories will undergo further refinement, slicing, rewriting. If the teams commit to stories then they are carving the plan in stone and Agility is fatally compromised.
Retrospective
Unfortunately it’s not over just yet; a retrospective is necessary.
This is important, because when do you think preparation for the next PI Planning begins?
Right here, right now.
If any changes need to be made to the preparation them they need to be known about now. The retrospecitve on planning can’t be deferred until the big retrospective at the end of the Planning Interval because that will be too late the preparation will be done and the next planning event imminent.
However, this is happening at the end of 16 physically and mentally draining hours, so the retrospective needs to be kept short and to the point. Personally, I use the Post-It note game: good, bad, change because teams tend to be familiar with it.
Central roles, RTE, Product Manager, System Architect, Stakeholers, etc… can participate by forming their own team. 5 minutes is given for individual brainstorming. Then 5 minutes for teams to compare the ideas coming from within the team. Then each team in turn presents 3 things, from any of the categories, to get a quick readout from the room to try and spot any common patterns.
It’s always gratifying that teams raise the Good things that they want to keep, as much as they complain about the Bad things that they want to change. After the event the Scrum Masters and Release Train Engineer can collect all the retrospective points in and process them offline.
Data Capture
Data Entry is not a spectator sport.
Transfer the data into any online tooling after the event.
Use the time in planning to discuss, negotiate and collaborate, it’s the one time when everyone is together, where conversations can happen in real-time.
Using it for the individual activity of data entry is a waste of that precious time.
Be wary of tooling. Teams become obsessed about keeping the tooling up-to-date so that the tooling can create the perfect picture. I always favour the simplest tooling possible, Post-It’s in the physical world, online whiteboards in the digital world, to encourage “individuals and interactions over processes and tools”.
Next
That concludes PI Planning, a plan built from the ground up, by the teams, for the teams and commitment to delivering as much of that plan as can be sensibly expected and ideas for how the process should evolve have been sought.
That evolution can be problematic. Evolution has to occur to adapt the process to suit the needs of the business, but it is very easy to evolve away from the underlying principles. The next article will cover some of the common challenges as ARTs seek to retrospect and evolve.
Training & Support
If you’ve never done PI planning before it’s a daunting task. There is training to explain what’s happening but for many some guidance to steer them through their first PI Planning event is very useful. You want people that have done it before, seen the situations, that know how to read the room. There aren’t many consultancies with comparable length and depth of experience.