Sometimes larger stories are broken down into smaller stories that can be tackled across multiple teams. For example, imagine that your organization has two teams: a team that owns your web application and a team that owns your mobile application. If you are releasing a feature across both platforms, you may originally start with that feature described as a single user story but then split the story in two as each team tackles their respective implementations.
When multiple teams work on a single product, it’s important that they work from a single product backlog that all teams share. This lets the product manager see the big picture at any given time, which helps to keep them focused on the overall vision for the product.
Even if a larger story will ultimately be split across several teams, it’s often helpful to keep it as a single story while it’s in the product backlog. This helps prevent you from getting mired in the weeds of each story too early, and makes the story easier to move up and down the backlog as new priorities emerge.
Keeping the story as a single unit also makes it easier to estimate. Sure, you know that the estimate won’t be as accurate as if your team broke the story down and estimated each individual piece—but that’s OK. We accept that estimates are less reliable at this stage of the process and only use them for getting an idea of the story’s complexity relative to other stories in the product backlog.
However, once your teams begin sprint planning, the top stories in the product backlog are moved into a separate sprint backlog for each team. At this point, those same large stories are broken down and split into separate stories for each team, each of which then take this opportunity to estimate their individual pieces. The sum of these new estimates may add back up to match the original estimate of the large story, but don’t be surprised if they don’t. Breaking larger stories down into smaller stories often tends to expose gaps that weren’t originally considered when the story was in its larger form, so it’s not uncommon for new stories to emerge as a result.
But don’t despair—adept product managers can still view stories across all of their teams at the same time by using a tool such as Pivotal Tracker, which allows them to view backlogs from multiple projects at once.
One of the advantages of allowing each team to work from their own sprint backlog is that it encourages each team to minimize the number of dependencies that are necessary to deliver their work. Ideally, each team has all of the skills necessary to deliver an increment of the product during each sprint, which is just one of the reasons why scrum teams should strive to be cross-functional. If a team can deliver a valuable increment of the product by themselves, then that makes it easier to split that work across teams.
Most scrum teams primarily plan by velocity, which is simply a measure of how many story points each team completed in the previous sprint. Teams who estimate in story points eventually start to evolve those points to the range that makes the most sense for each team. As a result of this, one team’s 3-point story may be wildly different than another team’s. However, this flexibility is what gives story points such predictive power since each team learns to assign the most accurate value to each point that makes sense to them.
While at first it may sound as if the varying velocity scales across team will wreak havoc with your planning, it’s actually not as large of an issue as you may expect. For one reason, these varying scales only come into effect at the sprint level and therefore are unlikely to affect your long-term planning.
And speaking of your long-term planning: these estimates are already accepted to be less precise given the vague knowledge that you’re likely to have of each story at this time. Therefore, your teams can simply agree to choose one team’s estimation scale to estimate stories at this level. The chosen estimation scale will be the scale used in the product backlog, which will give you a consistent scale for use in your long-term planning, as well as a single scale that all teams can agree on when estimating high-level items.
Splitting stories across multiple teams can be a valuable tool for scaling your teams to meet the demands of a growing product, but it doesn’t have to be hard. By simply keeping in mind the tips above, you can help your teams work together to deliver even the most ambitious stories on your product backlog.
Jeremy Jarrell is an agile coach who helps teams get better at doing what they love. When he’s not mentoring Scrum Masters or Product Owners, Jeremy loves to write on all things agile. You can read more of his thoughts at www.jeremyjarrell.com, see his videos at Pluralsight, or follow him on Twitter @jeremyjarrell.
Category: Productivity
