Visualisation is one of the key benefits of any Agile approach. This is often done with physical boards.

However it has to be appreciated with 20+ teams with six or seven domains that the number of boards gets quite demanding. Especially when items move from team to team or when complex interdependencies need to be managed.

With such complexity plus mixed granularity (Epic, Features, Themes, Stories, Tasks) it is certainly necessary to support the teams with electronic solutions, plus physical where appropriate. Physical boards can then be assembled in a central location where everyone frequently meets. These will be the “information radiators” that Kotter advocates.

First however, a slight detour! We need to look at the capacity allocation of the teams. Each individual team has two main sources of demand:

  • Stories from Business Epics from Product Management
  • Stories and defects for which the POs are responsible

So how much capacity should each team have for each demand? Should the allocated capacity split change? If so, when? Well the answer is simple: Product Management have to decide the allocation of capacity and have to review this with each Agile Release Train (ART). In other words, the capacity for each team can be reset with each Release Planning “heartbeat” of the enterprise.

The Boards

At the top level there is a single portfolio board. The items on this board move very infrequently yet the backlog, selected and in-progress can be very large. Prioritisation is key. So use Weighted-Shortest-Job-First.

The results of WSJF calculations are however, simply a guideline that clearly indicate the top 5 business epics and the bottom five. At least we know where to focus development effort and where we have to refine business epics still further. In reality, being dogmatic about the results of WSJF is ill-advised. It is just an indication. It is however, the conversation that occurred to get there, that is valuable.

In the middle layer, we have the program boards. There will be one for every single ART and is filled with features.

Then we have the individual team boards that have the stories.

But that is not all. Each PO may have their own board. They need to triage incoming demand (small change requests & defects) which may have to be broken down into stories and refined with the team. After all, they are responsible for certain quota of available capacity in the teams.

It is then a skill to bring the Product Management demand from the features on the Program board and the Product Owner demand onto the team’s sprint backlog.

Want to read on? Then click here to discover where SAFe is safe to use and where it may not be

Are you considering SAFe?

Want to know more about our experiences? If so, then contact us. We’ll be more than happy to hear from you.