Product Backlog

Splitting User Stories Across Teams

I recently received a question by email wondering if large user stories should be split across teams.  The question was so interesting that I thought I would summarize my response here.

Sometimes large user stories are broken down into smaller stories that are tackled by 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 we like to keep a single Product Backlog that all teams share. This lets the Product Owner see the big picture at any given time which helps keep them focused on the overall vision for the product.

Even if a larger story that will ultimately be split across several teams we tend to keep it as a single story during the Product Backlog phase.  This helps to prevent us 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.

Product Backlog

Keeping the story as a single unit also it makes it easier to assign an estimate to.  Admittedly, we know that the estimate won’t be as accurate as if we broke the story down and estimated each individual part, but that’s ok.  We accept that estimates are less reliable during this stage and only use them for getting an idea of the complexity of a story relative to other stories in the backlog.

Splitting User Stories During Sprint Planning

However, during 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, who then take this opportunity to estimate their individual portions. The sum of those 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 we didn’t originally consider when the story was in its larger form, so new stories may emerge as a result.

Product to Sprint Backlog

Allowing each team to work from their own Sprint Backlog minimizes the number of dependencies each team needs to complete their work.  We want each team to have as many of the skills as possible to complete a valuable increment of the product during each sprint, which is one of the reasons why we strive to make scrum teams cross-functional.  If a team can still deliver a valuable increment themselves, then we want that work split only into the portion that they can complete.

In addition, Velocity is our primary planning metric in scrum.  Teams who estimate in story points eventually start to evolve those points to the range that makes the most sense for each team.  Put another way, a story point for one team may be wildly different than a story point for another team.  This flexibility is what gives story points their power as each team starts to assign the most accurate value to each point that makes sense to them.

The side effect of this, however, is that the Velocity of two different teams can start to vary wildly even if each team is completing roughly the same amount of work.  For this reason we want to be able to map a separately velocity to each team which better represents the amount of work they’re completing during a sprint rather than trying to roll all velocities into a single number.  This gives us a more accurate representation of how much each team tends to complete during each sprint, which lets us plan the overall product even better.

Want to learn even more ways to split your user stories so your team can start working with them immediately? Check out my course, Creating Effective User Stories, for easy techniques that will have you writing better user stories today.

Don’t have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.

Read more...
User Stories, Themes, and Epics are often represented by sticky notes

Themes versus Epics in 2 Minutes

The difference between themes and epics are a common sticking point for many teams first diving in to user stories. Not only can descriptions of both topics often be vague, but the difference is often muddled further by many project management tools that use the two terms interchangeably. However, the difference doesn’t have to be so hard.

Read more...
railroad spike

Stop Estimating Spikes!

The most common question that teams face when first working with spikes is whether or not to estimate these stories. Luckily the answer is simple…don’t.

The whole point of spikes is to help us learn more about stories that we don’t yet know enough about to estimate well. This very unknown nature means that estimating the spike itself would be fruitless. Instead, our goal is to learn enough during the spike that we can estimate the associated story in an upcoming sprint.

Read more...
Paper Dolls

Turning Your Standups on Their Head

The daily standup is one of the most powerful tools in the scrum toolbox, so powerful in fact that when teams move beyond scrum they often still retain the standup as one of their core practices. But, there’s still room for improvement.

Read more...
timestamp-sticky

Meet the Timestamp Sticky

It’s no secret that teams who track their progress using physical tools rather than electronic have have a much higher rate of success, but how do you handle of the fear of sticky notes falling off the wall?

Read more...
Blue Sticky on White

Stories versus Themes versus Epics

When a new team is just beginning to adopt Scrum the difference between stories, themes, and epics always seem to be a source of some confusion. In particular, where stories end and epics begin tends to be a particular sticking point. In this article, we’ll take a closer look at each artifact to get a better understanding of the subtle differences between them so we can better communicate to our teams when each is appropriate for the work at hand.

Read more...
Load More
10 of 17