Scaled Agile Framework – Release Planning

At the end of my last blog post on SAFe - Scaled Agile Framework – The Team Level - I said that I would devote an entire post to the Release Planning session as this was one of the key meetings in SAFe.  This post covers the following points:

  • What is Release Planning?
  • What is the Release Planning Session and how does it relate to the PSI and Release Management?
  • The PSI/Release Planning meeting

What is Release Planning?

When we kick-off an Agile project, the very first thing we will do is some form of collaborative, deliberate discovery workshop to determine the initial set of User Stories that will be worked on by the team(s). As part of this workshop we will often encourage the Product Owner to prioritise the stories into releases (the number of releases depends on the size of the project), as a way to determine what holds most value to the business and what needs to be worked on first. XP (eXtreme Programming) actually names this collaborative workshop “Release Planning”, as does SAFe.

The key thing to understand with Release Planning and the resulting Release Plan is that the further it looks into the future, the more volatile it’s predictions become.

SAFe understands this and suggests that teams only draw up a Release Plan for the next 3 months of work. In SAFe 3 months of work is known as Potentially Shippable Increment or PSI (covered in my previous post), So although the Product Management team will probably have a Roadmap looking ahead up to 3 PSI (9 months) ahead, the teams will only have a very clear picture of the current PSI (3 months). The feature content of each subsequent PSI will get less clear the further away it is.

This approach is very similar to Rolling Wave Planning project management where work is planned in time periods called “Waves”. Rolling Wave Planning is used on projects where progressive elaboration – iterative development – is required, usually as a result of tight timeframes and the necessity to re-priortise the scope of the work accordingly in order to meet schedule milestones. Sounds like Agile, right?

The Product Management team of one of our key clients has used Rolling Wave Planning very successfully to plan the work for one of our Scrum teams for past 5 years, a total of 135 Sprints. They plan in 3 month Waves, starting off each year with a 1 year, 4 wave, Roadmap.


What is the Release Planning Session and how does it relate to the PSI and Release Management?

SAFe literature calls this session Release Planning, but this meeting isn’t necessarily about determining what will be in the next actual release of software to our users. Instead it determines what the teams will be working to deliver for their next PSI (Potenially Shippable Increment). Granted, for some finishing a PSI will coincide with actually releasing the product, but for others they may choose to release off the PSI cadence, at times determined by the Release Management team. This is something that Dean Leffingwell refers to as “Develop on cadence. Deliver on demand”. Whichever way your organisation works, what the teams will be determining in their Release Planning meeting is what they will be designing, building and testing in the next 3 months, or 5 – 6 sprints.

In some of the SAFe literature I notice that they refer to the release as the PSI/Release, for me that really clarifies it.

Anyway, onwards and upwards, let’s look at the Release Planning meeting.


The PSI/Release Planning Meeting

The PSI/Release Planning meeting precedes that start of work on the first/next PSI. So, if the project is just about to kick off, the meeting will take place before the start of the first Sprint. If the project is already underway and are about to complete their PSI then this happens during the HIP (Hardening/Innovation/Planning) sprint.

The Release Planning meeting is attended by all members of the program. The aim of the Release Planning is the following:

  1. Align the teams to the Program’s vision/objectives for the next iteration of the product.
  2. Provide guidance for both UX and Architecture, just enough to maintain consistency across the organisation/program and enable the teams to complete their work.
  3. Provide the teams with face-to-face, high-bandwidth-communication, planning time to determine how they will work together to build the next PSI. This will include resolving any dependencies between the teams, identifying and, where possible, mitigating any risks.


An example agenda looks something like this:

Release Planning - Sample Agenda

The primary objective of the first day is for each of the teams to take ownership of one or more features from the Program vision and create a Release Plan for the team. They do this by taking the feature(s) they’ve selected, and with the involvement of their Product Owner, break them down into stories to which they will give rough estimates. Each team will then map the stories into Sprints for the PSI, create a risk sheet (using colour coded post-it notes) and try to resolve any inter-team dependencies by verbally negotiating with the other teams. The final and most important output is a set of SMART objectives that the team will be working to for the coming PSI. The Product Owner will work with the team and other members of the Product Management team to assign business value to each objective so that the team is able to priortise accordingly.

Release Planning - Team Artifacts

Once the individual teams Release Plans start to take shape, they will start to add what they know to the overall PSI “Program Plan”. This highlights the new features (blue post-its), feature inputs (yellow post-it notes),  anticipated delivery dates and any other relevant milestones (orange post-its). Most importantly it visually represents any dependencies the teams may have across their product with pieces of string to link the dependent items. These dependencies will no doubt be high on the identified risk sheets of the relevant teams.

Release Planning - PSI Program Plan

This activity takes up most of the afternoon of the first day and is co-ordinated using a Scrum of Scrums approach, i.e. each team will send a team member to the hourly Scrum of Scrum meeting so that they can co-ordindate their Release Planning activity and determine if they are on schedule.

Once the PSI “Program Plan” has taken shape and/or the timebox expires, the Draft Plan Review will take place. This again is a tightly timeboxed meeting where the teams will present the highlights of their draft plans to all members of the Program.

This feeds into the final meeting of day 1, the Management Review & Problem Solving session, where the Program Management team meet to discuss any challenges presented by the draft Release Plan. The intent of this meeting is to resolve those challenges by negotiating scope and potentially resourcing.

At the start of day 2, the Program Management team present their suggested planning adjustments and the teams breakout to adjust their plans accordingly. Once the team has re-determined their objectives for the PSI, the business owners will make any adjustments to the business value for each objective if necessary.

During the Final Plan Review, the teams will present their plans to the entire group. At the end of each team’s timebox they will present their list of risks and impediments, but note, they don’t try to resolve them at this stage. If the plan is acceptable to the business owners, the team brings their PSI objective and program risk sheets forward to aggregate with the other teams.

Once all teams have presented their plans and the full set of objectives and risks is presented is assembled at the front of the room, the group work together to “ROAM” the program risks. The ROAM acronym stands for the following: Resolved, Owned, Accepted, Mitigated.

One by one the risks will be assessed, discussed openly and categorised into one of the above groups.

After the risk assessment activity is complete, the team will take a confidence vote, usually in the format of a fist-to-five vote. Closed fist demonstrating zero confidence, up to 5 fingers which demonstrates complete confidence. If the level of confidence is low, the plans will need to be reworked and any necessary adjustments made. Once the teams’ confidence is high, the plan can go forward.

The final step is for the group to carry out a Planning Retrospective to capture what went well, what didn’t go well and what could be done better for the next Release Planning session.

The outcome of 2 days of collaborative workshopping is a Release Plan for the PSI. This will, just as with XP, get refined and re-prioritised once more detail becomes available as work on the PSI progresses.

The smiley face game

In most cases your first idea will not be your best idea. In order to illustrate this concept we recently did an exercise with our Agile Coaches. We first came across this activity when some of our team members attended Jeff Patton‘s Passionate Product Ownership course. Jeff calls it Circles, we called it the smiley face game.

This exercise is best for 3+ people.

Materials you’ll need:

  • one sheet of A3 paper per person
  • a sharpie for each person



  1. Ask participants to fold their A3 paper lengthwise, then in half, and half again until they have folds that form 16 squares.
  2. Give them 2 minutes to draw different smiley faces in each square. If you see people are stuck, mention that they can be creative and think of animals etc when drawing smiley faces.
  3. After the 2 minutes is up ask them to pass their paper clockwise to the person next to them and ask them to tick the smiley face they like and cross the one they don’t like. Ask them to keep passing the papers clockwise until they end with their own paper.
  4. Once they have their own paper in front of them ask everyone to put their hand up if they have ticks in the first row of squares, then the second, third and fourth.
  5. Then ask if they have any crosses in the first few rows and ticks in the latter rows.


Usually you’ll find that people get either few or no ticks in the first row of smiley faces, this nicely illustrates that the first idea (or smiley face in this case) is not their best idea. You can see this when you look at the page as a whole as well, the lower half of the page tends to show better, more creative smileys.

The Board – Episode 25

Today’s episode was based on Jeff Sutherland’s blog post “Can You Define Agility?”

Jeff Sutherland has a competition running at the moment to come up with the best definition of Agile.

During the show our Agile coaches talk about “What is Agile?” and come up with their best definition of Agile.


Next week we will have  Jake Creech, CEO of Boost Agile China joining us and he will share his experience of working in China with Agile.

New free workshop – An introduction to running Agile projects at scale

Last Friday we ran our latest free workshop “An introduction to running Agile projects at scale“.

Intro to running Agile projects at scale

What does it mean – Scaled Agile Framework (SAFe)? 

The Scaled Agile Framework for enterprise – SAFe – describes a framework for scaling Lean/Agile in the enterprise. The SAFe Big Picture highlights the individual roles, teams, activities and artifacts necessary to scale from the team, to teams of teams, to the enterprise level.

This workshop is run by Paul Flewelling, an Agile coach and certified SAFe Program Consultant.

Description of workshop

Scrum advocates a team size of between 5-9 for optimal results, but what happens when the product or value stream that you are developing requires a lot more than one Scrum team?

This workshop will look at what is possible when running a project at scale, we will describe a framework which can be used to manage at the team, program and portfolio levels of the organisation. We’ll also look at some of the lean/agile foundations that this framework is built upon.


At the team level we’ll show how teams are organised, how work is co-ordinated between teams and how each team determines what they will be working on. We’ll also look at the benefits of running feature driven teams over component driven teams.


At the program level we’ll look at how program management keep the work flowing to the Scrum teams as well as making it responsive and adaptive to change.


At the Portfolio Level we will look at how the needs of the organisation can be driven by the vision delivered by the Portfolio management team.


Along the way we’ll provide tips and pointers as well as looking at tools like Rally, which provides full online support for this way of working.

If you want to know more about SAFe sign up now through Eventbrite.


The Board – Episode 24

Happy New Year to you all.
The Board is back for 2014 with episode 24 .
Today our agile coaches talk about their agile resolutions they have set for 2014.

This episode was promoted by Mike Cohn’s blog post “New Year’s Resolutions for ScrumMasters and Product Owners“.

Here is a summary of their resolutions:

  • Kirstin – Ask powerful questions
  • Gavin – To be a better agile trainer, continuous improvement
  • Paul – Treat everyone creative, resourceful and whole

Topics discussed:


Scaled Agile Framework – The Team Level

The team level in the Scaled Agile Framework (SAFe) doesn’t look very different from any other Scrum team setup. SAFe advocates the use of a hybrid of Scrum and eXtreme Programming (XP), which isn’t unusual. Most teams that adopt Scrum will adopt practices from XP whether they know where these practices originated or not: User Stories, Test Driven Development, Simple Design, Pair Programming and Continuous Integration have become widely accepted as good software engineering and allow the team to maintain high quality while moving at speed.

Co-ordination of teams with SAFe

The way that SAFe manages co-ordination across teams is where added structure starts to appear. SAFe is used for running Agile projects at scale, 50 -125 people working on one value stream, and because we’re using Scrum and Scrum advocates an optimal team size as 7+ or -2,  we will have multiple teams working on the same value stream.  This will mean, at the very least, that teams will have inter-team dependencies to resolve. SAFe manages this by putting some structure around the Scrum teams in a few ways.

  1. It advocates that the teams operate on the same cadence, i.e. the sprint duration is the same across all teams.
  2. The teams synchronize their sprint start and end dates, this enables better co-ordination between teams.
  3. It suggests that Potentially Shippable Increments (PSI) of a product of this size will only be possible after an arbitrary number of sprints are completed, nominally 4 or 5.
  4. SAFe advocates the use of a final Hardening/Innovation/Planning (HIP) sprint at the tail end of the series of sprints.

The HIP sprint

The HIP sprint is used for the following purposes:

  • Hardening: Ensures that technical debt is reduced and time is given for any speciality testing that needs to take place, e.g. system wide performance testing.
  • Innovation: Providing time for teams to follow up on ideas and out-of-the-box thinking.
  • Planning: Assess progress and complete PSI/Release Planning for the next period.

A prerequisite to the planning that takes place during the HIP sprint is the Inspect and Adapt workshop, a meeting that is used by the entire group firstly to assess progress made in the last PSI, secondly to determine what can be done to improve their process in the next. The Inspect and Adapt workshop is akin to the Sprint Review and Retrospective used by the individual teams at the end of each of their sprints.

Other activities in the HIP sprint will include putting aside time for continuous education, infrastructure activities and so on. The HIP sprint is characterised by having no backlog items that provide new value and is purely devoted to the activities described above. Allowing time for these activities during the HIP sprint means that the development cadence can be maintained year around, with no special scheduling adjustments required.

SAFe advocates the above structure to drive alignment between the teams so that they can steer towards a common goal for the PSI without having to think about the dates or timings of the other teams. The pattern, x sprints + 1 HIP sprint, will be familiar to anyone who uses Rolling Wave Planning, a planning technique used specifically to allow for progressive elaboration.

The team backlog

The final piece of the puzzle at the team level is how each team determines what is on their respective Product Backlogs, also known as the Team Backlog in SAFe. As with any implementation of Scrum, each item on the Team Backlog is a work item, these work items are determined by the team in conjunction with their Product Owner. The team is able to add work items as it sees fit, but the Product Owner has overall ownership and it is up to the Product Owner to prioritise the work as they see appropriate.

The main driver for the work items are the team objectives for the PSI, these are determined by each team during a planning session at the start of the PSI. This session is known as the PSI/Release Planning session and is a 2 day session involving all teams, it is one of the key meetings in SAFe and is important enough that we will devote the next blog post to it.

SAFe Program Consultant (SPC) Certification

I’ve just returned from a week of SAFe (Scaled Agile Framework) training with Dean Leffingwell and Al Shalloway in Seattle, USA.

Apart from the excellent hands-on training style that is so often a part of agile training sessions and the sheer density of the well thought out course material,  I also really enjoyed the opportunity to engage with some of the leading people in the Scaled Agile community.

Dean Leffingwell (SAFe’s Chief Methodologist) has industry experience second to none, having been a part of the iterative development movement, in particular the Rational Unified Process, one of the major precursors to the Agile movement.

Al Shalloway’s company, Net Objectives, has been Agile as long as I can remember and is an industry leader, Al himself is a thought leader, particularly when it comes to Lean and Kanban.

As with all my visits to the States, I try to tone down its sometimes larger than life nature and look at its sheer scale from a pragmatic perspective. When all is said and done our endeavour is the same even if the scale is different.

And running Agile projects at scale is what SAFe seeks to address, value streams of work that span many different teams. The SAFe framework and its curators don’t claim to have all the answers, and nor should it or they. After all, each organisation is different and has different ways of achieving its goals. SAFe is merely a framework which like all good Agile frameworks, encourages you to inspect and adapt your process.

One of the key attributes of SAFe that makes it so attractive is that it seeks to address how the existing Portfolio and Program management levels interact with the Agile (usually Scrum/XP) teams who are actually building the products. It merely seeks to make these management levels operate in a more Agile way.

Over the coming weeks I’ll write a series of blog posts around different aspects of the Scaled Agile Framework, sharing my learnings and understandings as best I can.

An unexpected Scrum graphic

Nathan recently returned from Shanghai with a Scrum handout that was quite different to any we’d seen before:

Scrum ladies

Produced by a Japanese company, these manga-esque characters are a lot more cutesy than we’re used to!


Do you need a Scrum Master?


Recently Alistair Cockburn, one of the 17 original Agile Manifesto authors, posted a question he was asked by a person called Gaboo, about the role of the Scrum Master.

Part of any Agile process necessitates stopping and thinking about the quality of the product you are producing as well as the quality of the methodology that is being used (12th principle ~  At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.) With this in mind, questions about whatever framework we may or may not use should not only be asked, but embraced and seriously thought about when brought up.

Gaboo wanted to know:

  1. Is there anything implicit which says that the Scrum Master must have background in software process improvement and psychology?
  2. If they don’t have a professional background, how can they judge team dynamics and software development issues?
  3. How can the progress of the team or the performance of the Scrum Master be measured?

I immediately saw why Alistair posted this question. These are all extremely valid questions as the role of the Scrum Master is a bit hard to understand in the business world. Managers are responsible for planning, delivering projects and organising the team. If a Scrum Master isn’t directly responsible for delivering the product and the team decides how they want to organize themselves, what is the Scrum Master responsible for and what kind of skills do they need?

I posted a response to Gaboo’s questions and I answered as best I could without using definitions and doctrine. I tried to focus on my experience with the Scrum Master role and how it fits into our team’s dynamic.

  •  Questions 1 & 2 were similar and I tried to tie them together with this response: 
    It doesn’t hurt to have experience in software if you are coaching software teams, but not in order to solve their problems. It may be useful to have similar experiences to that of the team so you can relate to them. The Scrum Master position is concerned with enhancing productivity through collaboration, not through software or a commanding influence.
  • Question 3, about measuring the progress of the team and Scrum Master, I answered with:
    I think the only way I can attempt to share any insight on this is to indirectly answer your question with the thought that Agile (Scrum) is a framework to encourage empirical thinking/reasoning in a team. If a team isn’t iteratively looking at what it’s producing and how it’s producing it, it isn’t progressing. Because of the iterative nature of Agile (and thus Scrum) this evaluation is always being made. Though there are many tools to measure progress and influence, the very act of iteratively analysing the team is a progress indicator unto itself.

To get the full context of my answers, and a few more tid-bits concerning the Scrum Master’s role with impediments, you can read my full response on Alistair’s blog post on Why do we need a Scrum Master?

These are my thoughts on the subject. I’d be interested to hear about anyone else’s experiences/reservations on the role of the Scrum Master.