Cross-Team Stories: How to Make Them Work

Ponder this scenario…

Suppose you have an Agile team building applications based on data API’s that are managed by a services team. Suppose that you cannot change the structure of the organization. If changes are needed to get a different data field from the API in support of a feature in your app — what do you do?

The answer is a cross-team story.  A cross-team story is really two parts: the validation piece of the story stays with the team that identified the need, and the actual development work story goes to the team that completes the work.

If both teams are running in Sprints, the shortest timeframe for completion of a cross-team story is two sprints. One sprint for the team doing the work, and one sprint for the validation of the team that identified the work.

A cross-team story workflow may look something like this:

1. During release planning or sprint planning, a team identifies work that must be delivered by a different team.

2. The team identifying the work creates two stories.

3. The product owners of the respective teams negotiate priority and scope of the story.

4. The team doing the work plans the story into their sprint. If the team doing the work uses a Kanban methodology, sprint planning is skipped and an expected date is communicated to the identifying team.

5. After the work is complete, the identifying team plays their validation story. This story could have been scheduled in a sprint based on the sprint, or an expected date from the work team.

6. When cross-team stories are identified prior to release planning there is an opportunity to play risk cards to ensure both teams are aware of the priority of the story, and the dependency can be manager by the Program Team or Portfolio Team. The tracking of the dependency can be accomplished in the Scrum of Scrums meetings.

In most organizations cross-team stories are rare. Many cross-team stories increase the risk of delay in delivery. If you notice that your team is always dependent on other teams to complete any functionality, this may be an indication that the skill set or architecture is not aligned with business priorities. This misalignment should be escalated to the Portfolio Team for resolution.