The Agile approaches in system development rely very heavily on the concept of user stories. A user story is a brief statement about how a specific user might use the system so that he achieves a specific outcome. It is often stressed that this outcome must be expressed as something of value to the business.
An example user story might be: ‘As a system administrator, I can configure the access rights of users, so that I can restrict access to sensitive areas of the system.’
Identifying the users of the system to be developed is one of the first steps the development team should take (see for example Mike Cohn’s ‘User Stories Applied’). To ‘identify’ users does not mean identify the actual persons, but rather to identify roles.
A role is the capacity in which the user interacts with the system. An example of a role might be the system administrator who is in charge of configuring and maintaining the system. Another example is an assistant who is responsible for printing reports from the system. A third example is a data entry person who uses the system to input data. And so on.
In addition to the organisational position occupied by the user, it is also encouraged that the system designers further look at finer grains of the roles. Rather than simply think of the system administrator as one role, think of possible types of system administrators because doing so can bring insights into what the role will need when using with the system.
A highly experienced system administrator very familiar with the system will have different needs than an experienced system administrator new to the system, who will also have different needs from a system administrator by accident, and so on.
By further classifying the roles, we begin to realise that not all system administrators are the same. They have different backgrounds. They may have the same responsibilities, but they may have different capabilities and capacities.
Mike Cohn recommends the project team to hold a brainstorming session near the beginning of a system development project to identify the various roles that will be catered. In this session, every team member writes down roles that they think about. After everyone has written down the roles, the team collects the list and refines them, merging similar ones, and further splitting others.
A couple of observations can be made:
1. The way some authors use the phrase ‘user’ they seem to be not very clear whether they refer only to those who will be actually using the system. If that is the case, the definition excludes those stakeholders who do not use the system, and therefore some other exercies is needed to identify the larger set of stakeholders.
For example, if the system is an immigration department front-end used by immigration officers (and never touched, or even viewed, by passengers), are passengers to be considered as users? I would suggest they not be considered as users, but should be considered as some other kind of stakeholder (a very important class of stakeholder; not to be ignored), and a separate exercise to identify these kinds of stakeholders need to be performed.
2. I would also suggest that after identifying the users, and cleaning up the list, a second exercise be taken to note down the key interest of the user with regards to the system. Why does this user have to interact with the system – what are their responsibilities to the organisation?
