Do you have user stories that need the expertise of more than one team? How do you organize this?
The situation
Your specific situation might be slightly different, but here is a common situation I have seen:
The company organizes around a few technical platform teams who build the platform/architecture/tech-foundation, which is then used by business-oriented teams to implement customer-facing features. This setup is pretty common and – though not fully cross-functional – also generally compatible with agile frameworks like Scrum.
Now a feature request from the customer comes in. How do you distribute the work between the teams?
Naive solutions
To get the feature from customer request to done, it takes at least two teams: the business-oriented team that implements UI and business logic, and the platform team that provides general platform functionality demanded by the business-oriented team to do their work. Both teams depend heavily on each other for implementation, testing and domain knowledge.
Platform & business user story
Defining two user stories, one “platform user story” and one “business user story” would make you end up with “stories” that have no clear business value for the customer; in fact these “stories” would be useless to the customer on their own. So by definition these would not be “user stories”.
Furthermore it is tricky to define the responsibility for the final feature (i.e. integration and QA). If both are responsible, experience tells us that nobody will be responsible.
One “shared” user story
Sharing one user story to two team backlogs is difficult. Who estimates the size? Who decides when it is done? So sharing a user story mostly leads to cloning a user story.
A cloned user story
Having two separate copies of a user story – one for each team – is another naive solution. Both stories are identical, but can be started and finished by each team according to their own schedule. Now you count the story points of this stories twice (aka magic duplication of velocity) and nobody knows who is responsible for what (especially for integration).
What’s the problem
There are two central problems with splitting the work using one of these naive solutions:
- You end up with non-releasable “user stories“. The stories are tightly coupled and have no business value on their own.
- Nobody feels responsible. Each team blames the other for blocking them or breaking things. Each team relies on the other to ensure quality.
In the end this leads to blame games, quality problems and slipping release schedules.
The solution
The solution is: Do not split user stories between teams! One user story should always belong to one team. That one team should have full responsibility for delivering the user story and full control over the means to get it to done.
A team can only take responsibility for reliable release dates and good quality, if they have all the means to get the story from requirement to done. But how do you do this?
Short-term
Considering the common organizations of teams into technical/platform and business-oriented teams we can do the following:
If team A picks the entire user story, but lacks expertise that resides within team B, simply assign a member of team B to team A for one sprint. Letting a member from team B move to team A gives team A all resources they need to take full responsibility for delivering the feature. Doing so for entire sprints at a time makes planning much easier and avoids putting the team member from B between a rock and a hard place on a daily basis.
Consider the teams a little more fluid. But keep teams together during the sprint.
Long-term
An even better long-term solution would be to move to fully cross-functional teams. Instead of having a platform and a business-oriented team, consider creating two customer-facing teams with full technology knowledge. If you’re worried about sharing your architecture decisions across two teams, let the platform-experts sync regularly in a chapter/community of practice/center of excellence.
Having truly cross-functional teams, that transcend all layers of your product, is the only way to true agility in the long-term.
Let me know how you organize your company. Do you have cross-functional teams? How do you cope with the situation of having to split a user story between two teams? What are your experiences? Reach out to me on LinkedIn or Twitter.