9. User Stories and Non User Requirements
What is a User Story?
A user story is a short and concise feature description written from the user perspective. The template for writing a user story is :
As a < type of user >, I want to < some goal > so that < some reason >
- Refers to the person who wants the new capability. It is typically the end-user of the product but depending upon the product for which you are writing user stories, the end-user could be internal to the company such as customer service manager
- Captures the user’s intent (or) need that they are trying to satisfy (or) job to be done. It does not cover details of ‘how’ the need is satisfied i.e doesn’t refer to the UI design
- What is the reason or motivation behind the user’s need (or) intent (or) job to be done? This conveys the benefit that the user gains when we help them achieve their goal or solve their problem.
The Feature Review phase, the Product Requirements Document (PRD) captures the following key aspects of the initiative:
- scope of the initiative
- impact of initiative on product goals
- identifies metrics and identifies the details of features at a high-level.
The Scrum team that is involved in developing and testing the product typically consults the product backlog that contains the prioritised list of features for detailed information.
Why do you need these features in the PRD?
The feature details from the PRD need to be broken down into manageable chunks that are clear, concise and written from a user perspective. This allows the development and QA team to collaborate with the Product Manager and Designer to discuss the details of how to support the feature based on the proposed design that was shared during project kick-off and updated based on feedback from stakeholders and feasibility input from the development team.
Product Description Statements for the Product Requirements Document
When writing your problem description statements, your voice ceases to be that of the customer and turns into a description of what the product will do.
The traditional format is written as follows for product requirements that must be met:
Option 1: Product MUST be able to perform [function]
Option 2: Product MUST provide [function]
Option 3: Product MUST have [function]
For those product requirements which you would like to have, but may not have time to develop, you can indicate how desirable it is to have this be part of the product.
Outline for the Product Requirements Document
Executive Summary: This rundown includes the product vision, objectives, scope, and risks.
Product Features: This detailed section defines the list of product features. This section will be at the level you know today, because Agile accommodates changes later on in the process.
Add to the list if needed and delete what isn’t applicable:
- Release Planning
- Functional
- Compatibility
- Security
- Performance
- Usability
- Operational
- Internalisation
- Documentation
- Support
- Legal
- Regulatory
- Compliance
- Distribution and Packaging
- Miscellaneous
Architectural Vision: What is the structure of the entire development project? What tools and processes will be used to create the entire product?
High-level Scope: This section outlines the needed resources, tools, dates, and milestones.
Risk Analysis, Assumptions, Open Issues: As with all documents, provide a risk analysis and note your assumptions and open issues.
Conclusions and Recommendations: Note your conclusion and recommendations
Exhibits and Appendices: Any supporting documents and further details.
PRD in an Agile Environment
Product Managers that don’t use agile requirements get caught up with spec’ing out every detail to deliver the right software. Then cross their fingers hoping they’ve spec’ed out the right things.
Agile requirements depend on a shared understanding of the customer, that is shared between the product manager, designer, and the development team. The Product Manager focuses on higher-level requirements and leaves the implementation details to the development team, who is fully equipped to do so, because of that shared understanding.
Creating a shred understanding:
- Conducting customer interviews, include a member of the design and development teams so they can hear from a customer directly instead of relying on the product manager’s notes. It will also give them the chance to probe deeper while the topic is fresh in the customer’s mind.
- Make developing and using customer personas a team effort. Each team member has unique perspectives and insights, and needs to understand how the personas influences product development.
- Make issue triage and backlog grooming a team sport as well. These are great opportunities to make sure everyone is on the same page, and understand why the product owner has prioritized work the way they have.
Who writes user stories?
User stories are normally written by Product Manager however; the scrum team members, and Product Designer can contribute too. The Product Manager confirms the details of the user story and acceptance criteria to ensure details are captured from the product backlog correctly. User stories are written and added to the product backlog throughout the feature development phase.
A product also has business-driven and system-level requirements that are not user-focused and seems like a misfit for the user-story format. For these write non-user stories that are simple and focus on detailing what needs to be done. For example:
- Track every single user interaction on every page at the browser and/or device level for Mixpanel trackingVerification phase, assigned to a QA person
Characteristics of a User Story:
- INDEPENDENT
Each story is self-contained and not dependent on another story
- NEGOTIABLE
Focuses on capturing a user’s needs without restricting how the user’s needs are resolved
- VALUABLE
Focuses on providing a clear value to the customer or end-user
- Estimable
Can be costed during sprint planning to effectively fit into a sprint
- SMALL
Can be developed and tested by the Scrum team
- TESTABLE
Can be tested using the acceptance criteria and definition of done
What’s in an acceptance criteria?
The acceptance Criteria defines how a particular feature could be used from an end user’s perspective. It focuses on business value, establishes the boundary of the feature’s scope and guides development. These are unique to a user story and form the basis of user story acceptance testing.
The role of a product manager is not to define what they think is the best delivery solution. The product manager, designer, and scrum team discuss after the kickoff meeting, the details of how to deliver the user story. Th goal being to deliver value to the customer, without adding unnecessary complexity or a convoluted user experience.
Acceptance Criteria establishes a boundary that helps team members to understand what’s included and what’s excluded from the scope of the user story. When the product owner verifies a user stories Acceptance Criteria and passes it, the development of the user story is considered a success.
Here are some examples of Acceptance Criteria for an app:
- Does this search result update dynamically as the user inputs their category?
- Is this search result updated when user completes that input?
- Should the number of exercises displayed be limited to five or eight?
- How many exercises are going to be displayed in the search results within that page view?
- Now, is that search results supposed to be paginated or load as the user scrolls?
- Is this search result going to have an image for all the exercises always?
- What happens if there is ever a scenario where the exercise doesn’t have an image? What happens then?
- What happens if an exercise has a long name?
- Does the name get trimmed or does it name move to the second line?
It can be a lengthy list of unknown or unclear information. When details are not provided, it results in a user story that was supposed to be marked as done by QA and engineering team, but ends with multiple issues created by the product manager that needs to be fixed. This scenario would require an extensive rebuild of the feature and waste the previous engineering work.
Non-Functional User Stories
Demonstrable working software that could not be completed within the confines of a User Story, and that can be verified by the team as complete.
These are an attribute or characteristic of the system, for instance:
- Performance e.g Response time, latency, throughput
- Scalability e.g Scale up, Scale down
- Reliability and Disaster Recovery
- Auditability requirements driven by regulations, legal and compliance
- Accessibility
- Support to run experiments and analytics tracking
- Browser and device compatibility
- Others include Security, Internationalisation, etc Reliability, Availability, Usability, Maintainability
Non-functional requirements can be seen as “constraints” put on the system. If a product owner said, “this system must perform adequately with 250,000 concurrent users,” the product owner is putting a constraint on the development team.
The product owner is effectively saying, “Develop this software any way you’d like as long as you achieve 250,000 concurrent users.” Each constraint we put on a system narrows the engineers choices; calling these “constraints” rather than “non-functional requirements” helps us remember this. Fortunately constraints/non-functional requirements can be easily handled as user stories. Here are a couple of examples:
- As a customer, I want to be able to run your product on all versions of Chrome.
- As the CTO, I want the system to use our existing primary database rather than create a new one, so that we don’t have one more database to maintain.
- As a user, I want the site to be available 99.999 percent of the time I try to access it, so that I don’t get frustrated and find another site to use.
- As someone who speaks a Latin-based language, I might want to run your software someday.
- As a user, I want the driving directions to be the best 90 percent of the time, and reasonable 99 percent of the time.
If requirement simply said: “Must use existing primary database,” it would be possible the engineers wouldn’t remember why we should be constrained in that way. We’d ask the product owner if they care if we used a secondary database, and they say they have no objections. And we’d make a mistake of using one.Embedding the person who wants something can be very useful.
Using API Documentation to Define Solution
Customers can use multiple products or applications to complete their desired task or job. For companies to thrive in the complex and competitive world and provide seamless customer experience, speed to market is key to success. Companies integrate with third-party APIs to expand into newer product segments while providing better customer experience. API stands for Application Programming Interface and it enables products or applications to talk to each other. API is the code that determines whether a product or application can access the server, and what information is it allowed to access or modify. Companies publish APIs with supporting documentation for partners to integrate. Partners utilise these APIs to launch new features or enhance existing features faster to the market instead of taking multiple quarters or sometimes years to develop them from scratch. Any newly developed functionality that is available via the API can be leveraged with minimal effort.
