Different users of your system may have different needs and be able to do different things. This is yet another logical way to try to split stories.
First, though, you need to identify the different types of users of your app. In my fictional Recipe app, I’ve already identified a few potential roles through the course of my blog series. So far, I have included:
- Users of the app with accounts
- An editor to review recipe submissions
- A publisher to ensure there is no copyright violation and to make the final publishing decision
Who else might be users of the app? I’m guessing there would probably be a few more, such as:
- Users who are totally new to the app and have never used it before
- System Administrators
Each role, or group of users, will have a different perspective and slightly different goals and/or outcomes.
In this example, I’m going to keep it simple and simply separate the users who have accounts from those who don’t.
Owners of the recipe app have decided they want to limit the capabilities of users who haven’t created accounts so they can entice them to sign up to get more robust features and recipes. The list features the unregistered user can access include:
- View lists of published recipes
- Search lists of published recipes
- Print recipes
- Share recipes on social media
The user who has an account will have access to a lot more features, such as:
- Save a list of “Favorite” recipes
- Create a shopping list for a recipe based on the user’s pantry inventory
- Sort recipes based on user’s preferences
- Filter recipes based on user’s preferences
- Tag and categorize their recipes
- Contribute recipes to be published
- Rate recipes
- Write reviews about recipes
- …and so on
This is another common approach to splitting out user stories. An excellent technique for helping to clearly identify which roles can use which features is called a “Roles & Permission Matrix”. It lays out all of features and capabilities on one axis, and on the other is the list of users.
Here is a sample matrix for my fictional Recipe app:
In this example, you could start with the stories that anyone can do, such as those under “Access Recipes”, and write a single user story for each function. But for other items that are specific to either a subset of users or single users, you would write separate stories based on the perspective of those roles. For example, only users with System Admin and Editor permissions can Approve or Reject recipes that were submitted for publishing. The story for that one could look like this:
This may or may not be a good approach to story splitting, depending on what it is. If you’ve been following my blog series, you may recall that we did split some stories up by CRUD operations. In some ways, this could be looked at as a cross between these methods since we are also listing out the different operations that can be performed in this matrix. The difference is that, when you start to have different permission levels, things start getting more complicated, and this might be a better way to split your stories than just by operations.
Questions to ask:
- Can you split out stories based on different users’ needs and perspectives?
- Do you really need to include stories for all roles?
- Could you start with the most basic users and add future stories for more advanced capabilities and additional permissions?
This approach to splitting User Stories is a fantastic one to help identify gaps, missing roles, or capabilities. It’s also great for applications that have lots of features, to ensure you’ve got everyone, and everything, covered.
