- Managing the Product Backlog
- Collaborating to Groom the Product Backlog
- Ranking User Stories with a Dot Voting Method
- Illustrating User Stories with Storyboards
- Sizing User Stories Using Comparison
- Splitting User Stories Along Business Values
- Tracking User Stories with a Collaboration Board
- Delivering a Coherent Set of User Stories
- Planning Work with User Stories
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Splitting User Stories Along Business Values
Most user stories are too large; at least, this is the trend we noted with teams transitioning to agile software development. We guess this is because it is difficult to understand the gist of what a user story is. We must go back to basics and remember that it was initiated by Extreme Programming (XP). In Planning Extreme Programming 4 by Kent Beck and Martin Fowler, a user story is defined in the following way:
- “We demonstrate progress by delivering tested, integrated code that implements a story. A story should be understandable to customers and developers, testable, valuable to the customer and small enough so that the programmers can build half a dozen in an iteration.”
A story is a short description of a unit of software that works, delivers value, and generates feedback from stakeholders.
A rule of thumb used to determine whether a story is small enough is to take the average velocity of the team per iteration and divide it by two. The velocity is the number of story points completed during a sprint. The product owner should not plan stories that are bigger than one-half the velocity.
A common mistake made when splitting stories is to slice and dice along technical issues, such as along the development process line (design, code, test, and deploy) or along the architectural line (user interface, business logic, and database). In addition to being difficult to deliver and deploy, technical decomposition creates stories that generate little feedback because they are incomprehensible by stakeholders. These stories negatively affect the iterative discovery of the stakeholders’ desirements. This is not the path to follow.
You should focus on the perspective of stakeholders by thin slicing stories that favor the business value. Thin slicing is based on evolutionary architecture; it provides stories that implement only a small bit of functionality, but all the way through the architecture layers of the software. Thin slicing always splits stories along self-contained increments of value and along self-contained bundles of work that include “design, code, tests, and deploy.” There are two usual patterns for thin slicing stories in a self-contained unit:
- Division: The division pattern provides smaller stories, often of equal size.
When there are clear boundaries about operational workflow or data manipulation, our first choice is to divide along these lines. For example, if it makes sense, you should split along the workflow steps involved or split according to each variation in business rules. If this is not a successful track, try to split by the type of data the story manipulates or along create-read-update-delete (CRUD) boundaries.
- Simplification: The simplification pattern aims to remove what is not necessary.
- When division is not an option, you should reduce the scope of a large story by keeping only the bare minimum. This is not a popular choice with stakeholders. As always, everything seems essential, and this requires more demanding conversations. Consider applying the XP principle: Do the Simplest Thing That Could Possibly Work. Remove from the large story everything that is not indispensable. Create one or more stories to safeguard what is not essential. These non-essential stories will be placed at the bottom of the backlog, whereas the remainder and thinner story will continue its journey to the top of the backlog.