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.
Further reading
* 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
I often wonder about how people expect agile in general (and scrum in the particular) to actually work if they don’t follow the core practices – not slavishly, but because they understand how projects work.
the user story structure, as simple as it is, contains three elements which are all critical to the success of the technique: persona (or type of user), goal and reason.
Most often i see the “reason” being ditched, and the next item is the “persona”, leaving pretty much a list of features, untraceable back to whoever is asking for it, and without any particular rationale against which to determine value.
a team of people working together need a framework to guide its organisation and endeavours. we all know how waterfall does this and the problems associated with these approaches. in agile we replace just about all those frameworks with more humanistic and flexible techniques, but they are still needed.
why a process would work if it’s not fully implemented is beyond me.