If you perform a search on Google for ‘how to split user stories’ you will get back some 87.2 million results. Many agile practitioners have their preferred methods, some with fancy names, others with complicated charts, and still more with double-digit principles or techniques. It feels like a lot of time, effort, and money has been spent trying to figure how to correctly or appropriately split user stories, but everything proposed so far still seems more difficult in its application than in its worth. To quote Kimberly Wilkins, “Ain’t nobody got time for that!”

What I want is something that I can use quickly and easily and that gives me great results. Also, something I can teach to others, product owners and business analysts, that they can quickly and easily grasp and begin using to effect. As it turns out, what I wanted didn’t exist. However, during my Don Quixote-like quest for an answer, I accidentally stumbled upon my own answer.

I was working as an agile consultant to a group creating a new web application to automate some complex internal business processes and enforce their internal business policies. There were two primary or chief Product Owners, their names, not mine, representing two different areas of the business. We took one large team (25-30 people) and scaled that into 5 right-sized teams. Each team had a dedicated business analyst (BA) acting as the team’s backlog owner (and each team also had a Scrum Master). We dedicated one team to each of the two business areas, one team to global functionality, and the other two teams to other functions (integrations and the like). After we scaled we really seemed to be rocking and rolling!

But then teams started to choke on user stories – user stories that were more like features and less like user stories. I began trying to educate the product owners and BAs on how to split user stories and breakdown features. We talked about the format of user stories – As a… I want… so that… We talked about the three Cs – card, conversation, and confirmation. We talked about INVEST – independent, negotiable, valuable, estimate-able, small, and testable. We talked about removing conjunctions from user stories (all of them that weren’t part of the original format!). We talked about vertical slicing as opposed to horizontal slicing. We talked about focusing on value. We talked about the relationships between and sizes of epics, features, and stories. We talked and talked and talked, but the user stories seemed to just keep getting worse and worse.

Then one afternoon, after looking at a particularly complex user story, it hit me! A ‘right-sized’ user story should have only one actor (as a… ), one action, and one target (I want… ).

1 x 1 x 1 = 1

1 actor x 1 action x 1 target = a behavioral complexity of 1

where the actor is the person/system role performing the action, the action is what is being done, and the target is what the actor is acting upon

and each actor, action, and target has an inherent internal complexity of 1 (i.e., no child subcomponents, sub-actors, sub-actions, or sub-targets)

I didn’t consciously understand why it worked at the time, but that’s the beauty of it, I didn’t have to. It worked whether I consciously understood it or not. I know, because I tested it. I tested it on those horrible user stories I mentioned before. I found one with a complexity score of 1 (not horrible at all). I found others with complexity scores ranging from 4 to 12. I found some others that had complexity scores in the 20s. And then I started to find ones with complexity scores of 60 or more. I even found one with a complexity score of over 100! At last I finally consciously understood what the problem was and how to explain it and how to fix it and how to communicate it all!

But you don’t have to take my word for it. Let’s take it for a test drive! Let’s start with a fairly commonplace idea – managing user profiles – and see where it goes. Let’s even go ahead and render our idea in the user story format…

As a registered user, I want to manage my user profile, so that I can ensure that it has accurate information about me.

At first glance it looks like we’re on the right track. We have one user type, ‘registered user’. We have one action ‘manage’. And we have one target, ‘user profile’. But what if we take a deeper dive into the actor, the action, and the target. What if each of those has a certain amount of complexity baked into them? Let’s start by asking some questions about each…

• Is there only one type of registered user or are there multiple types of registered user?
• If so, what are those types?
• Do they all need to manage their user profiles?

• What does ‘manage’ mean, specifically?
• Are there other component actions that fall under the ‘manage’ umbrella?
• If so, what are those actions?

• Is the user profile one thing or does it have component parts?
• If so, what are those component parts?
• Does everything get ‘managed’ all at once or can our registered user manage parts or pieces of his/her user profile?

Now, for the sake of expediency, let’s channel our inner stakeholder and provide some answers to our questions…

• Q: Is there only one type of registered user or are there multiple types of registered user?
  • A: No, there are multiple types of registered user.
• Q: If so, what are those types?
  • Freemium registered user, pro registered user, and enterprise registered user
• Q: Do they all need to manage their user profiles?
  • A: Yes.

• Q: What does ‘manage’ mean, specifically?
  • Add and remove a profile picture, enter, save, and delete profile information which includes first name, last name, email address, mailing address, and bio.
• Q: Are there other component actions that fall under the ‘manage’ umbrella?
  • add/remove profile pic, enter, save, delete text from profile info fields
• Q: If so, what are those actions?
  • See immediately above

• Q: Is the user profile one thing or does it have component parts?
  • It has component parts.
• Q: If so, what are those component parts?
  • Profile picture (assuming just one file type), first name, last name, email address, mailing address (assuming this is one field), and bio fields
• Q: Does everything get ‘managed’ all at once or can our registered user manage parts or pieces of his/her user profile?
  • Users can edit/update each individual field/component

Oh, wow! That’s a lot more information than we first thought. There was a ton of information hidden in our initial user story. So, let’s count our actors, actions, and targets again…

As a registered user (3x)

• Freemium registered user (1)
• Pro registered user (1)
• Enterprise Registered user (1)

I want to manage (6x)

• Add image (1)
• Remove image (1)
• Create profile information (1)
• Read/view profile information (1)
• Update profile information (1)
• Delete profile information (1)

my user profile (6)

• Profile image (1)
• First name field (1)
• Last name field (1)
• Email address field (1)
• Mailing address field (1)
• Bio field (1)

When this does happen, we should always go back and ask if each/any of the component parts (actor, action, and target) has component parts itself. For our little exercise we are assuming that the mailing address field is only on field. However, in most modern applications mailing address is composed of multiple fields: address line 1, address line 2, city, state/province, and postal code. But let’s assume that all of our components are composed of one field and have no further inherent (or inherited!) complexity.

Now, let’s plug all of those numbers into our complexity formula again…

3x6x6= 18×6= 108

Oh, my! That is wildly different from our first assumption of a complexity of one. The lesson here is to always, always, always check your actors, actions, and targets for inherent complexity, i.e., subcomponents. What we want within a single user story is for our actor, action, and target to each have an inherent complexity of 1 (or as close to one as we can reasonably come to), meaning that none of them have any unknown subcomponents. Knowing this, let’s try to split our original story solely along behavioral lines into smaller, less complex stories that have a behavioral complexity of or approaching 1.

Registered Users Managing their own User Profiles (our original idea)

1. As a fremium registered user, I want to add a profile picture, so that…
2. As a fremium registered user, I want to remove a profile picture, so that…
3. As a fremium registered user, I want to add my first name, so that…
4. As a fremium registered user, I want to edit my first name, so that…
5. As a fremium registered user, I want to remove my first name, so that…
6. As a fremium registered user, I want to add my last name, so that…
7. As a fremium registered user, I want to edit my last name, so that…
8. As a fremium registered user, I want to remove my last name, so that…
9. As a fremium registered user, I want to add my email address, so that…
10. As a fremium registered user, I want to edit my email address, so that…
11. As a fremium registered user, I want to remove my email address, so that…
12. As a fremium registered user, I want to add my mailing address, so that…
13. As a fremium registered user, I want to edit my mailing address, so that…
14. As a fremium registered user, I want to remove my mailing address, so that…
15. As a fremium registered user, I want to add my bio, so that…
16. As a fremium registered user, I want to edit my bio, so that…
17. As a fremium registered user, I want to remove my bio, so that…

Again, oh, wow! Now I have 17 user stories and that’s just for one type of user! If I have the same 17 user stories for each type of user, that leaves me with 17×3 user stories or 51 user stories! But wait a minute! Before we rush off and write all of those user stories let’s take a few minutes and run all of this by our developers to see if they need us to do that. In this case, they wouldn’t. Since all three of our user types can perform the same actions to the same targets in their own profiles, then we only need one set of stories that simply addresses the ‘registered user’. The lesson here is to ask your development team which of these different subcomponents matter to the work they are going to be doing. If it does matter, then we have to break them out. However, if it doesn’t matter, then we can keep the subcomponents lumped together and still keep our inherent complexity at 1.

This now leaves us with…

Registered Users Managing their own User Profiles (our original idea)

1. As a registered user, I want to add a profile picture, so that…
2. As a registered user, I want to remove a profile picture, so that…
3. As a registered user, I want to add my first name, so that…
4. As a registered user, I want to edit my first name, so that…
5. As a registered user, I want to remove my first name, so that…
6. As a registered user, I want to add my last name, so that…
7. As a registered user, I want to edit my last name, so that…
8. As a registered user, I want to remove my last name, so that…
9. As a registered user, I want to add my email address, so that…
10. As a registered user, I want to edit my email address, so that…
11. As a registered user, I want to remove my email address, so that…
12. As a registered user, I want to add my mailing address, so that…
13. As a registered user, I want to edit my mailing address, so that…
14. As a registered user, I want to remove my mailing address, so that…
15. As a registered user, I want to add my bio, so that…
16. As a registered user, I want to edit my bio, so that…
17. As a registered user, I want to remove my bio, so that…

We now have a feature with a complexity of 1x6x6=36. We also have 17 stories that each have a complexity of 1. Did I mention that development teams love user stories with low behavioral complexity? And if they love those stories, then it becomes that much easier for them to love the Product Owner who wrote them!

But wait a minute, you might be thinking! The complexities don’t add up – something’s not right here. And you are absolutely correct! When we lump children or subcomponents into our actors, actions, and targets, our inherent complexities multiply (i.e., they have a greater effect than when we take each one of them alone)! So, our feature from above has a behavioral complexity of 36, but we only need 17 stories with a complexity of 1 to build the feature! That’s the beauty of it! When we split out the complexities, we have less work to do, not more! 

Now, let’s review what we have learned from all of this.

• We want user stories that have only one actor with no hidden children (subcomponents).
• We want user stories that have only one action with no hidden children (subcomponents).
• We want user stories that have only one target with no hidden children (subcomponents).
• We want user stories that have a combined behavioral complexity of 1 (or as close to one as we can reasonably get).
• When we run across something with a behavioral complexity of more than one, we need to have a conversation with our development team to see if this complexity has an impact on the work they will be doing.
  • If it does, we need to split out those stories.
  • If it doesn’t, then we can keep those potential stories lumped together in one story.

I sincerely hope that this approach helps you by offering a new and much easier approach to splitting user stories. And, yes, I’m still working on a catchy name for it! And if you saw my “Splitting User Stories Doesn’t Have to Suck” session at the 2019 Agile Open Florida conference, yes, this is the exact same methodology we covered there. And lastly, you can find a visual representation of my 1x1x1 complexity model and methodology on SlideShare:

PO Survival Strategies (on SlideShare)

PO Survival Strategies from Mike Miller

Mike Miller on LinkedIn

https://www.linkedin.com/in/michael-miller-6b113916/

Huge thank yous to Dottye Stewart and Ashley Hintzen, who were there when the idea happened. Rey Ruiz for playing devil’s advocate, everyone at Clearly Agile, the Product Owners Group at Tampa Bay Agile where I first spoke about it, and for everyone who came to the session at the Agile Open Florida conference! You all rock socks!  😀