Agile practitioners are aware that Scrum has three roles: developer, ScrumMaster and product owner. In his book “Executable Specifications with Scrum”, Mario Cardinal also discusses how you can use the role notion in Agile to better understand stakeholders that have a different perspective, a concept that is also named “personas”.
Specifying the requirements from a single perspective does not reflect the experiences, backgrounds, and desirements of every stakeholder. While writing stories, it is important to identify all the stakeholder roles that the software must absolutely and positively satisfy. It is unusual that stakeholders come down to a single role. This is why the template for user stories begins with the section “As a , I want ….” It reminds us that there are several types of stakeholders.
A role is a collection of stakeholders pursuing the same desires while interacting with the software. A single stakeholder can fulfill more than one role. Whenever possible, stick with roles that define people as opposed to systems. However, consider a nonhuman role if you think that it may make or break the success of the software. A role must have a unique name that differentiates it and sets it apart from others, especially when it is read in user stories. For example, student, tourist, and worker are all good candidate stakeholder roles for “MTA Self-Serve Smartcard Ticketing Kiosk” software:
As a < student >, I want …
As a < tourist >, I want …
As a < worker >, I want …
In addition to retrieving the names of roles in the stories, some teams may feel the need to specifically record stakeholder roles with a short description. Any useful information that helps distinguish one role from another can be part of the written description. However, the aim of role modeling is not so much to create personas but to discover missing stories. By sorting stories by role, the missing desires for each stakeholder are highlighted.
Source: “Executable Specifications with Scrum”, Mario Cardinal, Addison-Wesley
The fact that there is only one product owner in a Scrum team who is responsible for managing and prioritizing the requirements should not lead us to forget that there might be more than one type of stakeholder that will use the application, sometimes with conflicting needs and priorities. The concept of “persona” has been used to manage different stakeholders’ roles or different types of customers. Defining the person with a name and sometimes a picture help the Agile team to have a more user-focused approach when discussing requirements. Some form of user research should be conducted before creating the personas to make sure that they represent end users rather than the opinion of the person writing them.
* About Face 3: The Essentials of Interaction Design; Alan Cooper, Robert Reimann & David Cronin, Wiley
* Agile Alliance Guide to Agile Practices: Personas
* User-Centric Design and the Power of Personas
* An introduction to personas and how to create them
* A Template for Writing Great Personas
* Agile Story Mapping: Personas In Action
* Personas in Agile Development: YES We Can!
* Agile, Multidisciplinary Teamwork