The Scrum of Scrums is an essential piece for ensuring highly complex, interdependent projects within a large Agile program remain connected. This is a critical enabling structure that can be scaled up or down depending on the demand that each feature team has within the conglomerate structure (I prefer this to the word ‘program’ as true value is always evolving and needs constant re-alignment). Whilst, there are enough ways to create an evolving structure, I believe the following visual columns usually work well and I have found them to be very useful.
Feature Team: The boring way is to have a number tagged purely for the purpose of identifying work against each of the teams, however a more interesting way is to have a theme around which teams choose characters that they closely associate with. Establishing avatars within the team makes it more vivid, enrapturing, colourful and most importantly visual enough for quick traceability in a busy board.
Business Outcome: I specifically advocate this column as it is important to remember that as a team only the highest value item should be delivered from the product backlog. The user stories in a product backlog should be aligned to a business outcome and sometimes these are treated being equivalent to a super-epic level. Whilst a set of teams can define their working structure, it’s important to have business outcomes that need to be fulfilled at least over the next two release cycles. This ensures that the team is productive enough to constantly deliver and user stories are available to be taken into the sprint planning sessions. Its important to remember that the business outcome are continually evolving and new outcomes can get established over time. I sometimes like to link them to mission statements as they become quantifiable and allow metrics to be evolved that allow ‘measure of success’ for the outcomes.
Release Backlog: In complex programs this is a must. The Release backlog only consists of those items that are being worked on within the feature teams. Its important to note that it is possible for ‘teams’ to work on an outcome or have ‘a team’ working on an outcome. Either way, this column helps as teams work only on high value items as well as ensuring that teams don’t work on conflicting outcomes that may delay releases. Of course, this is not the only reason for delay in releases. It’s important to understand that release preparation is all together another detail and is handled in different ways.
In transition: These are specific user stories that are within the ‘refinement/grooming’ phase. It’s important to understand that they need to be prioritized and should ideally be the next block of work that would potentially be committed. Do note that this does not mean that they cannot be swapped out. Urgency and demand are the two essential pillars that guides presence of a user story in the transition column. The importance of putting them ensures that teams on a SoS have a visual understanding on the pipeline of work and can be abreast of interdependency between user stories so that sprints in turn releases are not impacted.
Ready: This column indicates the user stories that are ready for the committed sprint and should limit itself to the current sprint. Its important that the definition of ‘Ready’ is clearly understood by all the feature teams. The I.N.V.E.S.T model is a great way to ensure that a set of user stories are ready and alignment is common.
Doing: More often than not, this column is often split further as teams often like to detail what stage each user story in. The most common is Build and Test. Its important to note that doing is a critical stage as it is actually the one that measures cycle time (the definition is not equivalent to time) of story points (or any other equivalent method) between the ready and done stages. Its important that all user stories that are within the ready state (committed) move through the sprint to the done state. Ideally a team has understood its capacity well to deliver and has established a trend of its cadence. In the early stages, new teams may over or under commit. Its important to note that good teams establish value based cadence and understand the importance of releases. More frequent the releases, the more the opportunity to take feedback and improvise.
Done: There are as many connotations to the definition of done as there are variants. Its important that teams hold closely to the definition of done. The simplest way to measure of course is to have an affirmative agreement from the product owner on completeness of the user story (usually measured via. the agreed and established acceptance criteria). This should include testing. The Definition of Done provides a checklist which usefully guides pre-implementation activities: discussion, estimation, design. Apart from this the definition of Done, limits the cost of rework once a feature has been accepted as "done". Having an explicit contract limits the risk of misunderstanding and conflict between the development team and the customer or product owner. This would list the user stories that were committed earlier as part of the sprint planning.
Ready for Release: The simplest alignment to this is the MVP. Complex programs often require interdependent stories to be complete before a successful release or each capability/feature set may be a release by itself. It’s important that interdependent teams are synergised enough to ensure that the release truly represents the value the customer is looking for. More frequent the releases the better and that should be the motto for any agile team.
Impediments: This is the ‘missing’ column. If it is ‘visually critical’ than making it present on a board is important as a separate column. Honestly, the importance is to get action on an impediment and just laying a red flag as a display or as a mark (bold enough to be seen) is enough to get action. It’s important that teams discuss and speak around the impediment.
Like everything Agile, keep evolving because perfection never really existed and good is relative. Visual mechanisms enable action but only if teams action themselves and ensure that they speak around specificity. Without action any visual board becomes stale quickly and devolves the traction in the team.