Another Story Splitting Pattern (Maybe)

User stories are typically written using a template like, “As a <role>, I want to <action> so that <value>.” My other story splitting patterns focus on complexity in the action part of the story. But sometimes the functional complexity in a user story is hidden in the role rather than the action. Consider: could you split the story by splitting the role and only satisfying a subset of potential users in the first story?

As the title suggests, I’m not sure this is actually a new pattern. Every example I can think of actually fits under another pattern. So, if you like, you can think of this as a thought experiment to identify simple/complex, business rule, data entry or other splits where splitting the role reveals a split somewhere else.

Share in the comments: Has discussing splitting the role for a story ever helped you find functional complexity to split the story? Can you provide an example? Is this a sufficiently distinct pattern to merit updating the original article?

Update, October 2020: Richard’s latest story splitting resources are available at Humanizing Work.

Related Articles


  1. I think I’ve split stories successfully by role. We used to include deployment/installation/upgrading as a part of stories. It was big drama, especially every time we added a new component.

    As a System Administrator, I can [deploy the new server], so that business users can [do their thing].

    As an [End User], I can [do my thing], so that [my thing can be done faster and more reliably than before].

    I see what you mean that this might be splitting by Workflow Steps though… but I thought of this split as by Role first. =)

    — S.

  2. Hi,

    I’ve also done some splitting by role for stories, however in my case it is a rarely applicable pattern to split my stories (at about 5%).
    For example in some CAD tool:
    – As a Designer I wan’t to have a customizable color scheme for my plan.

    in order to split it, we decided to build a new story:
    – As a Developer I wan’t to have a framework for customizable color schemes.

    In this way we could get rid on a plenty of GUI related tasks that allows the end user to choose and customize, but build the framework and all the stuff in the engine.

    What do you mean?

    I write about my experiences in scrum transition and agile programming at and would be happy to see your comments on my posts.


    1. @Tom

      Thanks for the comment.

      “As a developer…” stories are something of a red flag for me when I see them in a backlog. They look like you’re following the user story template while missing the value of user stories, which is thinking about features from a user perspective rather than a developer perspective. (I feel the same way about “As a PO…” and “As a tester…” in most cases.)

      For you customizable color scheme story, I’d probably look for complexity somewhere other than the roles being served. Maybe different kinds of customization, simple vs. complex customization, choosing between a finite set of color schemes vs. fully configurable, etc.


  3. Ok, I see your point, however I find it really hard to formulate each and every non-functional requirement from the user point of view. May be some of them just can be treated as constraints on the application (e.g.: performance), but what about architectural requirements, such as a service infrastructure that needs to be implemented, or if the application requires a specific test framework for automated GUI testing?
    How would you manage such development efforts in scrum? Is it acceptable in such cases to use actors like Dev, PO, etc… ?

    1. @Tom – I like to see non-functional requirements like performance, testing, etc. captured on a definition of done and satisfied as part of each story. I like to grow infrastructure to support real user stories, a little at a time. If you actually do have to stop delivering user stories to do an infrastructure chore—say, installing and configuring a CI system—I have no problem seeing those chores on the backlog occasionally, but I think trying to fit them into the user story template is unnecessary (and hides the fact that you’re not actually building something for a user).

  4. HI Brian:
    yes indeed!
    Mary Gorman and i have written about ‘splitting’ (or slicing stories along 7 dimensions, 4 of which are functional requirements. one of the dimensions is User Role.
    “Slicing Requirements for Agile Success Better Software (feature), August 2010

    We’ve been using this strategy with clients for planning and preparing requirements for the “big-view” (product), “pre-view” (release) and “now-view” (iteration or, if using kanban WIP).

    Since we wrote the article last year, we have adjusted our use of some terms. You can equate:

    Article term = Training term
    Expand-Then-Contract = Explore and Evaluate
    Element = Dimension
    Object = Data Dimension
    Business Rule = Control Dimension

    what do you think?
    ~ ellen