I’m sure you’ve read that only drug dealers and software developers call their customers ‘users’. When it comes to agile software development, simply calling everyone who will run your software, ‘user’, is a problem.
Agile software requirements are usually captured as stories following a structured format like this:
“As a <user role> I want <goal/desire> so that <benefit/reason>”.
All too often, every story begins with “As a user, I want…”. User! I don’t think there is a corporate job title of “User”. The role of ‘user’ doesn’t convey any information about the business person running the software.
For the software developers to implement what the business community really needs, they have to relate to the job functions being performed. The business team won’t just be ‘using’ the software. They will be following a business process toward achieving an outcome.
The first purpose of stories is to help the development team understand who is running the software. To help figure that out, answer a few questions:
- What is the software user’s job title?
- What is the user’s job function as it relates to the software?
- What responsibilities does the user have that the software will help with?
Don’t just implement stories the way the technical team sees them. Create a mental image of the business person using the software to help the software developers implement the stories the way the business wants.
Exactly. A great exercise is to create “user personas” that the development and PO should understand. These user personas enable teams to fully understand what types of “users” use what specific functionality.
Comments are closed.