Three weeks after PI planning, the checkout team is waiting on the payments platform. At planning, the arrangement was simple: the platform team would ship a new API version in sprint two, and checkout would consume it as a service. Nobody drew a red string on the program board, because there was nothing to coordinate. Sprint two ended. The API needed one more change that only checkout could specify. The service became a collaboration, and the collaboration became a queue. Four stories have been blocked for nine days. The release board is still green.
Nobody designed the teams badly. The design held. What changed was the traffic across the boundaries.
What Team Topologies is
Team Topologies is an organizational design model published by Matthew Skelton and Manuel Pais in 2019. It describes four team types and three ways teams interact, with one goal: fast flow of change, with few hand-offs and a cognitive load each team can carry.
Team Topologies team types
- Stream-aligned team: owns one flow of work, such as a product or customer journey, end to end.
- Platform team: provides internal services that other teams consume as self-service.
- Enabling team: specialists who help other teams pick up a skill or practice, for a limited time.
- Complicated-subsystem team: owns a component that needs deep specialist knowledge.
Team Topologies interaction modes
- Collaboration: two teams work closely together for a defined period.
- X-as-a-Service: one team consumes what another provides, with little direct coordination.
- Facilitation: one team helps another clear an obstacle or learn a practice.
Choosing these boundaries is expert engineering judgment. The people who set them know where the code is coupled and where the expertise sits. When a stream-aligned team holds its confidence vote, that vote already prices the boundaries it can see. Nothing in this article replaces it.
Where the date still leaks
Every boundary is a dependency with a contract. The model reduces the number of crossings. It does not remove them, and after the vote the crossings change in ways the design document never records:
- X-as-a-Service stops being self-service. A missing capability turns a platform team’s API into a request in someone else’s backlog.
- Collaboration outlives its end date. Two teams agreed to pair for one sprint. In sprint four they are still pairing, and both teams deliver less.
- A complicated-subsystem team becomes the gate. Only one team can change the component, and three stream-aligned teams queue for it in the same week.
This is the second of the three things that erode a committed release date: dependencies surfaced too late. Scope creep and capacity changes, the other two, push the same date in the same direction. Conway’s Law predicts where those crossings will be. Team Topologies decides how they should work. Neither says what a crossing costs the date once it stops working as designed.
Price the crossings, not the org chart
The fix is not a new team design. It is to make every crossing visible where the forecast can read it, and to agree in advance what triggers a conversation.
- At the vote, record the committed date and the confidence level the team committed at, next to the ranked scope.
- Record every cross-team need as a Jira blocking link on the in-scope issue, including the X-as-a-Service ones. If it is not a link, nobody can see how long it has been waiting.
- Agree the trigger in days: when the forecast at the committed confidence passes the committed date, the two teams talk that week.
- Read the age of each open blocking link, not only that it exists. A nine-day-old block on four stories is a different conversation from one opened this morning.
- When an interaction mode changes, say so, and re-read the forecast the same day.
An illustration, not customer data. A release is committed for 22 May at 85% confidence. At the vote, the 85% forecast sits at 19 May: three days of margin. In week three, four in-scope stories have been blocked for nine days by the platform API change. The 85% forecast is now 26 May and the 50% forecast is 21 May, so the release reads amber. The two teams agree a collaboration with a fixed end date. The platform team ships the change five days later, and the 85% forecast returns to 21 May, back inside the commitment.
A weekly sync will surface the same blocker. As the article on why the Scrum of Scrums surfaces the blocker but doesn’t price the date explains, naming it is half the job. The other half is the number of days.
Where Advanced Release Planning fits
Advanced Release Planning for Jira does not model team structure, team types or interaction modes. It reads the crossings where Jira records them: blocking links on in-scope issues, including links to issues in other teams’ projects, and how long each link has been unresolved. Blocked work is treated as not yet startable. The Monte Carlo forecast re-reads the committed date against its 50%, 85% and 95% band, and the movement is reported in days and attributed to dependencies, separately from scope and capacity. The team sets the assumptions: which throughput window, whose capacity, what is in scope. The app does the arithmetic at Monte Carlo scale and keeps it live. On track at or above P85, attention between P50 and P85, at risk below P50. The app does not negotiate with the platform team or forecast its date. It tells both teams what the wait is costing the release. For exactly what is read, see the cross-team dependencies reference doc.
Key takeaways
- Team Topologies defines four team types and three interaction modes to reduce hand-offs.
- Choosing team boundaries is expert engineering judgment, and the confidence vote prices the boundaries the team can see.
- After the vote, crossings change mode: services become queues, collaborations run long, subsystem teams become gates.
- Record every crossing as a Jira blocking link, read its age, and price it in days against the committed date.
FAQ
What are the four types of team topologies?
Stream-aligned, platform, enabling and complicated-subsystem teams. Stream-aligned teams deliver the work; the other three exist to reduce their load.
What is a platform team?
A platform team provides internal services, such as APIs, pipelines or environments, that other teams consume as self-service. When a needed capability is missing, the service turns into a dependency on the platform team’s backlog.
Does Team Topologies remove dependencies?
It reduces them and makes them deliberate. It does not remove them. A stream aligned team still depends on platform, enabling and subsystem teams, and those crossings can change after a release is committed.
Design the boundaries on the team’s judgment. Price the crossings in days. See every blocked crossing priced against the committed date in Advanced Release Planning, or start a free trial on the Atlassian Marketplace.
Leave a Reply
Your email is safe with us.