Role-Feature-Reason
The role-feature-reason template, or RGB (role, goal, benefit), looks something like this:
"As a [type of user] I want [some feature] so that [some reason]."
Although there are variations, this short sentence structure keeps the focus on the who, what, and why. This prevents the product owner from giving the development team too much information about how they should implement a solution.
By focusing on the who, what, and why, the development team is empowered to find the best technical solution.
Example 1: Provide a trainer with the ability to add a course
As a trainer, I’d like to be able to add a new course, so that I’ll have the potential to attract new students.
Example 2: Provide a student with the ability to search for a course
As a student, I’d like to be able to search the course offerings, so that I’ll be able to find an offering that most interests me.
The role (who)
The role describes who will benefit from this function. Notice that the role is not simply “the user.” There are different types of users, and so we want the role to be more specific than “user” but describe the type of user that will benefit from the story. Product owners are often tasked with getting in the mind of their users in order to understand what would be most valuable for them.
Example 1 Role = trainer
Example 2 Role = student
The feature (what)
This step very briefly describes what the user wants. This most closely represents the requirement that you describe in traditional software development. However, you want to be careful not to be too specific or describe how to write the code. That will be determined eventually, but not when you first create the user story. The user story should be written from the perspective of the user who will benefit from the function, not from the perspective of the developer who will be coding it.
Example 1 Feature = add a new course
Example 2 Feature = search the course offerings
The reason (why)
Finally, we want to state why the user wants this feature. What value will the user get from it? This helps the product owner evaluate how to prioritize the user story on the backlog. If the value or benefit can’t be articulated, it might be something that’s not necessary. Understanding the value often helps the development team find innovative ways to implement the code in order to solve the objective—ways that may be different from what the product owner has in mind.
Example 1 Reason = attract new students
Example 2 Reason = find an offering that most interests me