Richard Lawrence » product management

New Story Splitting Resource

Richard Lawrence — Fri, 27 Jan 2012 18:41:27 +0000

More than two years after I originally published it, “Patterns for Splitting User Stories” remains one of the most visited posts on my blog. Splitting user stories continues to be one of the areas where the teams I work with most often need coaching.

To support the teams I coach, I’ve created a flow chart that goes through the questions I’ll ask when I’m helping a team split their stories. I was going to keep this resource for my coaching clients, but I’ve decided to share it here for free. Click the thumbnail below to download the full-size PDF version.

Let me know in the comments if you find this useful. If you can share them, I’d love to see examples of how you’ve used it, what the stories looked like before and after splitting.

Patterns for Splitting User Stories

Richard Lawrence — Wed, 28 Oct 2009 14:04:29 +0000

Good user stories follow Bill Wake’s INVEST model. They’re Independent, Negotiable, Valuable, Estimable, Small, and Testable. The small requirement drives us to split large stories. But the stories after splitting still have to follow the model.

Many new agile teams attempt to split stories by architectural layer: one story for the UI, another for the database, etc. This may satisfy small, but it fails at independent and valuable.

Over my years with agile, I’ve discovered nine patterns for splitting user stories into good, smaller stories.

(Note: As with any pattern language, I didn’t invent these patterns, I’ve just observed and compiled them. For example, this great post by Lasse Koskela put names on some patterns I’d observed but not named, especially “Major Effort.”)

How Small?

How small should stories be? I recommend 6-10 stories per iteration, so how small is small enough depends on your team’s velocity. Before your next planning meeting calculate what estimate should trigger splitting a story. For most teams, it seems to be 8 or 13 points. But on a recent project I’m doing by myself, I’ve needed to split 5-point stories.

When you’re in a planning meeting and you hit your trigger estimate, pull out the cheat sheet at the end of this article and try a few of the patterns until you find a good split.

Which Pattern to Use

You’ll often find that you can split a story using several of the patterns. Which split should you choose? I use two rules of thumb:

Choose the split that lets you deprioritize or throw away a story. The 80/20 principle says that most of the value of a user story comes from a small share of the functionality. When one split reveals low-value functionality and another doesn’t, it suggests that the latter split hides waste inside each of the small stories. Go with the split that lets you throw away the low-value stuff.
Choose the split that gets you more equally sized small stories. The split that turns an 8 point story into four 2 point stories is more useful than the one that produces a 5 and a 3. It gives the Product Owner more freedom to prioritize parts of the functionality separately.

Pattern #1: Workflow Steps

Here’s a story from a content management system one of my clients was creating:

As a content manager, I can publish a news story to the corporate website.

Didn’t sound too big—until we dug into the workflow to get a story published. It turned out that just to get a few sentence news story on the corporate website required both editorial and legal approval and final review on a staging site. There’s no way 6-10 stories like this would fit in an iteration.

In a workflow like this, the biggest value often comes from the beginning and end. The middle steps add incremental value, but don’t stand alone. So it can work well to build the simple end-to-end case first and then add the middle steps and special cases.

The new stories included:

…I can publish a news story directly to the corporate website.
…I can publish a news story with editor review.
…I can publish a news story with legal review.
…I can view a news story on a staging site.
…I can publish a news story from the staging site to production.

Pattern #2: Business Rule Variations

This story has a few equally complex stories hidden within it that accomplish the same thing using different business rules:

As a user, I can search for flights with flexible dates.

Digging into “flexible dates” reveals several different business rules, each of which can be a good story on its own:

…as “n days between x and y.”
…as “a weekend in December.”
…as “± n days of x and y.”

Pattern #3: Major Effort

Sometimes a story can be split into several parts where most of the effort will go towards implementing the first one. For example, this credit card processing story,

As a user, I can pay for my flight with VISA, MasterCard, Diners Club, or American Express.

could be split into four stories, one for each card type. But the credit card processing infrastructure will be built to the support the first story; adding more card types will be relatively trivial. We could estimate the first story larger than the other three, but then we have to remember to change our estimates if the Product Owner later changes priorities. Instead, we should defer the decision about which card type gets implemented first like this:

…I can pay with one credit card type (of VISA, MC, DC, AMEX).
…I can pay with all four credit card types (VISA, MC, DC, AMEX) (given one card type already implemented).

The two new stories still aren’t independent, but the dependency is much clearer than it would be with a story for each card type.

Pattern #4: Simple/Complex

When you’re in a planning meeting discussing a story, and the story seems to be getting larger and larger (“what about x?”; “have you considered y?”), stop and ask, “What’s the simplest version of this?” Capture that simple version as its own story. You’ll probably have to define some acceptance criteria on the spot to keep it simple. Then, break out all the variations and complexities into their own stories. So, for example, this story,

As a user, I can search for flights between two destinations.

stays simple by splitting off variations like,

…specifying a max number of stops.
…including nearby airports.
…using flexible dates.
…etc.

Pattern #5: Variations in Data

Complexity in a story can come from handling variations in data. For example, a system I’m currently working on needs to model geographic areas served by transportation providers. We could have burned our whole project budget just handing geography; it’s potentially that complex. When I talked through the story,

As a user, I can search for transportation providers by trip origin and destination.

with our Product Owner, I discovered that, while we didn’t need full-fledged GIS, modeling geography would still be quite complex. We stopped and asked, “What’s the ‘good enough’ way to model geography so we can build other high-value features now?” We settled on,

As a user, I can search for transportation providers by trip origin and destination as counties.

This worked for a while, until we collected more data and found that some providers only served certain cities or even neighborhoods. So a new story came up:

As a user, I can search for transportation providers by trip origin and destination as counties, cities, towns, or neighborhoods.

Looking over the new provider data, we also discovered that some providers will support trips originating in a single city but ending in any number of surrounding cities. This led to the story:

Providers can serve different geographic areas for trip origin and destination.

All three of these stories are split from the original geography story. The difference here is that we added stories just-in-time after building the simplest version. But sometimes you know the data variations up-front. The classic example is localization:

As a content manager, I can create news stories.
…in English.
…in Japanese.
…in Arabic.
…etc.

Pattern #6: Data Entry Methods

Complexity sometimes is in the user interface rather than in the functionality itself. In that case, split the story to build it with the simplest possible UI and then build the more usable or fancier UI. These, of course, aren’t independent—the second story effectively is the original story if you do it first—but it still can be a useful split.

As a user, I can search for flights between two destinations.
…using simple date input.
…with a fancy calendar UI.

Pattern #7: Defer Performance

Sometimes, a large part of the effort is in making a feature fast—the initial implementation isn’t all that hard. But you can learn a lot from the slow implementation and it has some value to a user who wouldn’t otherwise be able to do the action in the story. In this case, break the story into “make it work” and “make it fast”:

As a user, I can search for flights between two destinations.
…(slow—just get it done, show a “searching” animation).
…(in under 5 seconds).

Pattern #8: Operations (e.g. CRUD)

The word “manage” in a user story is a giveaway that the story covers multiple operations. This offers a natural way to split the story. For example:

As a user, I can manage my account.
…I can sign up for an account.
…I can edit my account settings.
…I can cancel my account.

Pattern #9: Break Out a Spike

A story may be large not because it’s necessarily complex, but because the implementation is poorly understood. In this case, no amount of talking about the business part of the story will allow you to break it up. Do a time-boxed spike first to resolve uncertainty around the implementation. Then, you can do the implementation or have a better idea of how to break it up. Don’t know how to implement the following story?

As a user, I can pay by credit card.

Then, break it into:

Investigate credit card processing.
Implement credit card processing.

In the “investigate” story, the acceptance criteria should be questions you need answered. Do just enough investigation to answer the questions and stop; it’s easy to get carried away doing research.

The spike split is last because it should be your last resort. You probably know enough to build something. Do that, and you’ll know more. So, make every effort to use one of the previous eight patterns before resorting to the spike pattern.

Conclusion

Resist the temptation to split an overly large user story by architectural layers. Instead, try these patterns to split your story into smaller stories that still satisfy the INVEST model. Let me know how it works for you or if you’ve run into unsplittable stories (I love a challenge!).

Download the Story Splitting Cheat Sheet

Agile Product Management Boot Camp

Richard Lawrence — Thu, 22 Jan 2009 03:52:29 +0000

Bob Hartman and I are offering an Agile Product Management Boot Camp course March 9-10 in Denver. If you’re a product manager, product owner, business analyst or in any other product facing role in an agile (or soon-to-be agile) environment, this intense, hands-on course is a great opportunity for you to ensure that you’re helping your team maximize the value it delivers.

Topics include…

Understanding Agile: Process and Driving Principles
Ensuring the Right Things Gets Built: Testing and Acceptance
Specifying What to Build: User Stories
Deciding What to Build First: Prioritization
Defining Customer Value: Minimum Marketable/Releasable Features
Project Acceptance: Building a Product Vision and Business Case
Product Management 101: Useful Tips, Tricks and Techniques
Pulling it All Together: Project Simulation

You will leave the course knowing how to:

Deal with the team outside of just planning meetings, demonstrations and retrospectives.
Break down requirements into usable stories – even when the team is unable to help.
Deliver value in stages rather than all at once.
Write acceptance criteria to ensure the right features are being developed.
Create a project business case and vision.
Perform basic product management functions in an agile way.
Effectively interact with customers, community, stakeholders, managers, and the team.
Make a convincing business case for using agile for more projects.
Continuously improve.

The course registration fee is $1,200, but readers of this blog can take advantage of a special 2-for-1 offer. Simply register with discount code RLB2FOR1, and we’ll send you another code you can give to a colleague to register for free. Seats are limited, so get your registration in today.

Short Answers #2: What to Focus on in 2009

Richard Lawrence — Sat, 03 Jan 2009 23:48:33 +0000

It’s officially a series now. In this Short Answers video, I answer the question, “If my Scrum team could work on one thing in 2009, what should it be?”

Of course, adopting agile engineering practices and getting better at product management are often easier said than done. If you’d like help getting started with some of the practices I mentioned in the video, I’m running a New Year’s training and coaching special with 7 ways to get 2009 started right for less than $2,000.

Books I mentioned in the video:
The Goal by Eli Goldratt
It’s Not Luck by Eli Goldratt

Are the Product Owner and ScrumMaster’s Interests Opposed?

Richard Lawrence — Wed, 26 Nov 2008 17:53:31 +0000

The Chief Engineer role in the Toyota Product Development System combines parts of the Product Owner, ScrumMaster, and senior technical team member roles from Scrum. In addition to leading the technical design of a new product and facilitating the work of the other engineers, the CE must deeply understand and care about what the customer values—he has ultimate responsibility for delivering value to the customer and for the resulting commercial success or failure of the product.

CEs have gone to amazing lengths to gain that deep understanding of the customer’s needs.

For example:

While developing Toyota’s successful 2003 Sienna, the Sienna CE drove his team in Toyota’s previous minivan model more than 50,000 miles across North America through every part of Canada, the United States, and Mexico. The CE experienced a visceral lesson in what is important to the North American minivan driver and discovered in every locale new opportunities for improving the current product. As a result, the Sienna was made big enough to hold full sheets of plywood while the turning radius was tightened, more cupholders were added, and cross-wind stability was enhanced, among many other improvements that resulted from this experience.

(From The Toyota Product Development System by James M. Morgan and Jeffrey K. Liker, p. 30)

If you’ve followed recent discussions on the scrumdevelopment group, you’ve seen multiple threads over the last couple months that discussed how the interests of the team, SM, and PO are intrinsically in conflict and that acting as both PO and SM requires a kind of useful schizophrenia.

I have to wonder: Toyota is one of the best product development organizations in the world. Are Toyota’s CEs a special breed, immune to the conflicts of software teams? Do the rest of us need distinct roles to balance our selfish interests?

At the very least, if we find that the interests of our POs, SMs, and teams seem to be fundamentally in conflict, we should ask why. Shouldn’t we all have the same goal: Producing valuable software now and in the future? Perhaps we should consider how to align around that goal rather than how to balance the interests of roles centered on lesser goals in the hope that we achieve the true goal as a kind of dialectical byproduct.

It’s one thing to say that the PO and SM roles ought not be combined because each is so demanding that it requires a person’s full time attention. But it’s quite another to say that the roles are fundamentally locked in a conflict too intense to be handled by a single person, and that better software results from that conflict.

Free Agile Product Management Seminar – Nov 11, Denver

Richard Lawrence — Thu, 30 Oct 2008 18:18:44 +0000

I’m hosting a free seminar on Tuesday, November 11 from 1:00-2:30 PM in the Denver Tech Center area. Please join me there and spread the word to others who might be interested.

Here’s a brief description:

Too many teams adopt agile processes like Scrum and XP, become effective at iterative and incremental delivery, get their software quality higher than it has ever been before, and finally achieve a sustainable pace…yet fail to harness that new productivity to deliver anything of real business value.

As an agile coach, I see Product Owners who don’t understand the features on their Product Backlogs well enough to explain them to the team in a planning session. I see Product Owners who can’t explain the larger context of a user story. I hear teams and Product Owners tell me that it’s not possible to come up with a valuable release that will take less than 6 months to build. I see teams demotivated because they don’t see the value in what they’re building.

In this free seminar, I’ll show how effective agile product management can accelerate and increase ROI, I’ll introduce an approach to identify high value feature sets, and I’ll share some tips on how to avoid getting bogged down in the details and losing the big picture.

You can find more info and register here: http://agileproductmanagement1108-rl.eventbrite.com.

How to Invest Less and Make More From Your Software Projects

Richard Lawrence — Tue, 14 Oct 2008 21:15:38 +0000

As the saying goes, “Cash is king.” It doesn’t matter how good your P&L or balance sheet looks or how good the business case for your project is, if you don’t have enough cash every month to pay the bills, you won’t stay in business.

With the economy tightening, then, companies are desperately trying to cut costs in order to stay cash flow positive. In IT the major cost is salary, so cutting costs means cutting people. Nobody likes that.

Fortunately, there’s a simple way to reduce expenses and increase returns on a software project: incremental releases.

A Typical Big Bang Release

Let’s look at a example. Our project will spend $1m (mostly salaries) for a year of development starting in January 2009, release at the end of that year, and is projected to make $2m over its first year in production. We’ll simplify this model and assume that expenses and returns will be distributed evenly over their respective years. We’ll ignore ramp up time and we won’t discount future cash.

The result is a cumulative cash flow chart that looks like this:

We spend money linearly until we’ve spent our whole million. Then, we release the software and start making money linearly until we make the projected two million. We break even in June of 2010, 18 months in, and we see a 100% ROI.

Variation 1: Incremental Releases

Now, let’s keep all those same assumptions and make one small change. Instead of building the software and releasing it all at once, let’s break it into four equal size feature sets. Every three months we’ll build and release one until the whole product is released. To simplify things again, we’ll assume that each feature set is equally valuable and will account for a quarter of the expected return. Since we can start seeing returns as soon as we release a feature set, our cumulative cash flow now looks like this:

With this arrangement, we only need to invest $375k in the project rather than $1m. We break even in February 2010, 14 months in. With an investment of $375k for $1.75m in returns ($2.75m in revenue less the same $1m in expenses as the previous example) we see a 467% ROI over two years.

Variation 2: Prioritizing Releases by Value

For most projects, however, value isn’t distributed evenly across the features. Usually an 80/20 rule applies and some features are much more valuable than others. For our hypothetical project, let’s assume that we can divide up our features to get a pretty typical distribution where Feature Set A accounts for 50% of the value, Feature Set B for 30%, Feature Set C for 12%, and Feature Set D for 8%. Now, our cumulative cash flow looks like this:

When we deliver feature increments by value, we have to invest only $250k for a $2.1m return, or 844% ROI. We break even in November 2009, before the original project was even going to release!

Variation 3: Cutting Out Low-Value Releases

Once we’ve prioritized our features by value, we can go one step further. We can decide that some features aren’t worth the investment. With their long 15 and 19 month waits to break even, feature sets C and D may not be worth it. Over the two years we’re considering, those features have a negative ROI. Let’s cut them out of the project and have the team do something else more valuable. Here’s our cumulative cash flow now:

This variation generates less revenue, but only spends half as much. The return is $2.15m on a $250k investment, or 860% ROI. It breaks even in August 2009, tying up the cash for less time and freeing the team to do something else more valuable. In fact, if we can assign the team to two feature sets on another project as valuable as A and B were on this project, our two year cumulative cash flow looks like this:

Now we see $3.5m returned on our $250k investment, an ROI of 1400%. We break even in October 2009, still three months before the original plan would have had us starting to see a return at all. Simply by rearranging our work by value and releasing incrementally, we’ve dramatically improved our cash flow situation while increasing our revenue. And we didn’t have to lay anyone off to do it. Going into a tight economy, odds are that this is exactly what your business needs.

(In case you’re interested, here are the details behind the charts: big-bang-vs-incremental-releases-cash-flow.xls.)