When we’re creating or extending systems, there’s often one type of user that’s our main focus. We often have no trouble thinking up capabilities they need. But other types of users are often forgotten.
We need to enlarge our view, to the whole project community. We need to consider the full set of stakeholders – all those affecting and affected by the project. These other perspectives can be critical to the success of products.
The ideas below are certainly not a complete list, but I hope they spark you to look for missing stories.
Features and Constraints
A feature is a capability of a system, typically triggered by a condition or action. We often think of user stories as describing a feature.
A constraint is a limitation on a solution, describing things that must or must not be true. Some people embed these as user stories, but they’re also often more freestanding requirements.
Both are important, especially for forgotten stories.
The Business
The business that develops, purchases, or provides software must monitor and manage itself. A business often has measurable goals, and often needs reports and/or dashboards that help them understand whether they’re meeting those goals.
The business also needs to configure software for use. (We’ll leave hardware/system configuration to Operations below.) For example, a sales application may need the catalog of items for sale and their prices. Someone has to set these up, track them, and keep them updated.
Management may need to audit applications or databases for business and/or legal reasons. For example, an audit might regularly check that all charges recorded for a day match the amount deposited at the bank.
Legal Requirements
Governments – at any level – impose legal requirements on businesses. (It shouldn’t surprise you – but I’m not a lawyer. Get the legal advice you need.)
For example, publicly traded companies in the US are required to do their accounting using GAAP – Generally Accepted Accounting Principles.
Other laws target specific industries. In banking, credit card companies are legally required to track whether customers are willing to accept marketing phone calls.
You may be subject to different laws depending on where your customer is. Europe’s GDPR rules are a prime example of this: they apply to European users even if your company is based elsewhere. For example, this affects how you track users.
Email in the US must conform to CAN-SPAM laws. For example, to reduce spam, these laws require that you don’t use misleading subject lines and that you provide a way for people to get off mailing lists.
The ADA (American Disabilities Act) imposes rules that require accessible websites for some organizations.
All these laws (and many others) may impose requirements for things you must or must not do.
Marketing
The marketing department may have its own special needs. Some examples:
- Configuration – Marketing is often the part of the business configuring text, images, catalogs, discounts, etc.
- Ability to send messages
- Feature flags, to control access to (usually new) features
- A/B testing – to provide different experiences to different people, to help you figure out which way better accomplishes the business’ goals.
Operations
For a software product, someone has to run it. Sometimes this is the end user. In other cases, e.g., SAAS (Software as a Service) the overall business is responsible for it.
To support operations, you may have stories in these (and other) areas:
- Deploy the system – set up the target systems and install the software
- Manage licenses and access to third-party systems
- Uninstall / decommission the system
- Enhance observability – e.g., require a correlation id (see References)
- Monitor the system / alert operators
- Investigate problematic situations
Tiers of Use
It’s very easy to start by focusing on core users and features that support them, but you often discover you need multiple levels of access.
The first special level that pops up is often “Administrator”. While some administrative actions may be done behind the scenes by programmers or Operations, it’s often convenient to have an administrative mode inside the application.
At the other extreme, we often find we need a “Guest” level: something with lower privileges for those not signed in, or those in a “free” tier.
Beyond these, you may grow to need other user levels or capabilities. For example, if you support accounts for corporate buyers, you may find that they want their own administrative features, but only to control their own users.
Disfavored Users
There are some “users” who we have to consider, not because we want to support them, but because we want to thwart them. I learned the term “abuser story” years ago from Judy Neher, and I’m looking forward to her forthcoming book. (See References).
For these stories, we’re often trying to prevent something from happening. In that respect, they impose constraints on our solutions.
Disfavored Users – Abusive People
Any system that stores personal information about people can be a target for people who are improperly trying to find other people.
Think of all the words we’ve built up for various types of abuse – troll, online lynch mob, doxxing, cyberbullying, swatting, … Social media has made these issues even more urgent. I don’t have answers, but here are some concerns:
- Anonymity vs real names – There’s a tension between anonymity and the risks of requiring real names.
- Privacy controls – Who can learn what about you?
- Not accidentally revealing locations or habits – For example, photos may embed location data that you’d rather not reveal.
- Means of reporting and addressing abuse.
Disfavored Users – Hackers
Security concerns induce both constraints and features. Some constraints:
- Data must be encrypted both in transit and at rest
- URLs shall not be guessable
- No components with known security vulnerabilities will be used
The OWASP Top Ten (see References) makes other suggestions.
There are features too:
- Reset a password
- Close an account
- Confirm an identity
- Require 2FA to sign in
Security is a specialty area; get the advice you need appropriate to the risk level of your system.
Conclusion
The primary users of a system often are not the only users of a system. So, you need to consider a broad range of stakeholders, making sure you haven’t forgotten any key ones.
References
Hilton, Peter. “Correlation IDs for microservices architectures” – https://hilton.org.uk/blog/microservices-correlation-id – retrieved 2021-07-05.
Neher, Judy. Agile Security: A Security-Driven Development Approach with Abuser Stories. Forthcoming.
OWASP.org. “OWASP Top Ten” – https://owasp.org/www-project-top-ten/ – retrieved 2021-07-05.