Our Process
User Story
Both use cases and user stories refer to user requirements that describe what users can do using a system.
A use case consists of a list of interactions between the user and a system (e.g., a digital product). It aims to document and organize users' actions so that you know when each interaction happens and at what stage of the customer journey.
Often, business analysts are responsible for creating use cases and collecting user requirements.
A user story describes a product's features from the user's perspective. Kent Beck mentioned this term in the book "Extreme Programming Explained." Its task is to explain what users want and why they want it.
It's a popular method used in agile methodology (agile user stories) to communicate user needs in a way that is understandable even to a non-technical team member. User stories help you deliver both customer and business value.
User stories can be written by product owners, stakeholders, or product managers.
Do you want to create a User Story?
Use case and user story: Examples
A use case could look like this: "Bookstore — update customer profile."
Meanwhile, a user story would read: "As a customer, I want to update my profile so that future purchases will come to my new home address." It's important to consider that users have different needs.
A user story goes beyond indicating the user's goal and describes the user's motivations.
How to write user stories?
You can begin user story mapping by finding a user story template that will help you describe three crucial elements.
Role
A role signifies the user: "As a user/customer/manager, I want to..." It's important to note that users aren't development teams or stakeholders. They should be the actual end users of your product. It's crucial to remember this because your product tries to satisfy customer needs as well as business ones.
Action
An action describes how the system will behave in response to the user. For example: "As a customer of an online store, I want to be able to change profile information." It also allows you to define what the customer needs.
Benefit
A benefit provides the context and determines why the user wants a given functionality. It's a result that the customer hopes to achieve: "As a customer of an online store, I want to be able to change profile information so that my ordered products are delivered to a new home address."
You may also ask yourself: When are user stories written? There is no specific development stage at which you should write user stories. You can create them throughout the software development cycle.
Characteristics of a good user story
You can review user stories according to the INVEST checklist. It will allow you to determine the quality of user stories.
The INVEST method means the following:
- Independent. An independent user story should work regardless of other user stories. You should be able to implement it by itself.
- Negotiable. User stories don't need to be set in stone. They can change and evolve during the development process.
- Valuable. A user story should provide users with a value.
- Estimable. You need to be able to estimate user stories so that you can properly prioritize them.
- Small. Implementing a user story should take your development team a couple of days.
- Testable. A user story should be confirmed by using acceptance criteria.
Software: User Story vs. Acceptance testing
Writing user stories allows you to perform acceptance testing (related to acceptance criteria).
The purpose of the acceptance test is not to detect errors but to obtain confirmation that the software has reached sufficient quality.
This is how you determine whether you have met the customer/stakeholder's requirements.
Testing occurs early in work, translating into satisfactory results, regardless of the methodology adopted.
The details of a user story are determined based on acceptance criteria rather than the written requirements.
While testers will assess whether a requirement has been implemented correctly, they can't tell what the customer/stakeholder will say about the software.
When you realize a requirement needs to be changed, you must inform the business analyst.
You should follow the change control process defined for the project, which will ensure that changes aren't missed and the impact of each change is analyzed.
But what if the subsequent user stories are too big to be implemented in a single iteration? You divide them into smaller user stories and implement each of these stories during separate iterations.
Users and their requirements. The problem with the initial project assumptions
Requirements are specifications for what should be implemented.
They describe how the system should behave, define its properties or attributes, and may impose constraints on the system development process.
There are more definitions of user requirements, but the above one is one of the most accurate.
Among the methods representing user requirements are use cases, user stories, and event-response tables.
User requirements refer to the objectives or tasks that users can perform with the product.
Moreover, the requirements also refer to the description of product attributes or characteristics related to meeting users' needs.
To present user requirements, you can use, among other things, user stories.
A user story helps establish a project's final priorities, but it must be realistic to ensure high effectiveness.
While doing so, remember how important the opinion of the development team is.
It's all about setting realistic goals, so pay attention when the team says that, for example, it is impossible to prepare a software feature in the requested time.
However, sometimes, a project goes far beyond the initial assumptions.
Then, you must reduce its scope, extend the work schedule, set aside additional funds, or find more hands to do the work.
User story: How to identify user requirements?
To identify the user's requirements, you should define the tasks the user has to perform with the software.
It's also essential to choose the objectives they're trying to achieve. Requirements can be described with a user story, use cases, and scenarios.
User story: Collecting requirements and iterations
When developing digital products, requirements are collected, analyzed, detailed, and updated throughout the solution design phase.
However, this doesn't prevent the product owner from deciding at any time, even at the development stage, that something needs to be designed differently.
In such a situation, the business analyst will undertake a requirements update, where their crucial task will be to check how a change in one requirement can affect other system requirements.
Collecting requirements can be done in many ways.
Among the most popular are workshop methods, in-depth interviews, analysis of laws, norms regulating the market, analysis of constraints (e.g., technical), observation of user behavior (e.g., towards the existing system you want to replace), observation and process mapping, etc.
The business analyst classifies the acquired requirements into appropriate categories (functional requirements, quality attributes, business rules) and decides whether they fit into the digital product's vision. Then, they're divided into so-called production iterations.
It's worth dividing into iterations with the product owner, who will determine to what extent a particular functionality is essential to the solution's usability and attractiveness.
You can also consider iterations as implementation scopes. The wider the scopes, the more blurred they become.
The collected requirements are the basis for the IT systems requirements analyst, who breaks down the requirements according to their implementation priority. The business owner participates in this process.
There are many methods of prioritization, with the most common being the "MoSCoW" method, in which all requirements are divided into a four-point scale: "must," "should," "could," and "won't."
Various variations of this method are on the market, such as the use of a three-point scale: "must be," "should be," and "nice to have."
To assess prioritization, you need to know the digital product's key competitive advantages and critical functionalities, as well as the estimated cost of implementation.
One of the more advanced and very accurate prioritization methods is the "House of Quality" method, about which we will soon write a separate article in the context of web application production.
Once the requirements are prioritized, you should divide them into production sprints, which may have a predetermined budget and duration.
The problem of meeting requirements
What causes the application's target users to be dissatisfied with the IT system? You may have encountered a constantly dissatisfied malcontent, but that doesn't have to be the case.
The problem is rooted in the expectations gap, the differences between what users actually need and what has been implemented.
Such a situation can occur, for example, when you emphasize listening to the needs of a group of stakeholders who won't ultimately use the software.
Often, when developing a digital product, some stakeholders want to meet their needs that aren't necessarily in line with the product's vision, or when conducting interviews, people with a more powerful voice demand the introduction of their specific guidelines.
You try to bend the functional requirements according to the outside and irrelevant force. That is why it is essential that the person who collects the requirements has high interpersonal skills and can conduct the facilitation professionally.
Agile software development and scrum to the rescue
It's worth remembering this because you live in a dynamic world of business and technology, where continuous cooperation with the customer has become indispensable.
Hence, the popularity of MVP, design sprint, and scrum is growing. In other words, the agile methodology is gaining ground every year.
Agile methodology
The agile methodology was born in Silicon Valley in the '90s, although the name didn't appear officially until 2001. At that time, the "Agile Manifesto" was published as a set of principles to improve work on software projects.
The manifesto claims that people and interactions are valued more than processes and tools and that working software is more important than detailed documentation.
In turn, cooperation with the customer is more important than negotiating contracts, and responding to changes is more important than implementing the established plan.
Agile is the opposite of the waterfall model, characterized by rigid patterns and a lack of flexibility regarding changing customer needs.
Scrum vs. How does the end user look at the project?
Scrum, an element of agile software development where user stories are involved, is divided into sprints, i.e., stages of work lasting up to four weeks.
Thanks to this, changes are made on an ongoing basis, and the customer is constantly involved in the process of creating the product.
When you receive information that the given functionalities don't meet expectations at the end of a sprint, you can make adjustments in the next sprint. You can always quickly change functionality for another or save money by abandoning an idea that didn't work.
The product owner plays an important role in the scrum. They create a list of sprint needs and present the work results to customers and users for feedback.
However, before the product owner takes action, their work is preceded by sprint planning. You should limit the planning process to a maximum of eight hours if the sprint lasts a month.
We recommend the book Agile Estimating and Planning, written by Mike Cohn, one of scrum's creators, to those interested in the topic.
It's a publication that gives an excellent introduction to the characteristics of agile methodology and will undoubtedly be helpful if you want to work using user stories, among other things.
Software: An example of how the customer plays a huge role in its creation
The rule is simple: the more frequent the contact with the business owner or target software users, the easier it will be to stay on the right product development path.
Experts say that the series of meetings will reduce the expectation gap at the project's end and produce solutions closer to the target customer's actual needs.
Agile projects are characterized by requirement management, usually taking the form of user stories in the requirements register.
During planning sessions, the product owner and the team agree on the stories to be implemented in the next iteration.
Such a set of stories is selected based on their priorities and the development team's efficiency.
What happens next? Once a set of stories is selected and approved, they're "frozen," and the proposed changes to the requirements will be considered in future iterations.
Agile projects don't attempt to get stakeholders' approval of the full range of requirements upfront; in their case, the complete set of functionalities emerges over time.
However, remember that the vision and other business requirements should be defined at the beginning.
Product backlog: How to prioritize and what role the development team plays in this process
How to prioritize the product backlog, a list of needs that consists of requirements and functionalities?
It's helpful when the development team shares information about the costs and risks associated with each requirement. A user story can also be used to determine final priorities.
Having realistic priorities can help developers produce maximum value at the lowest cost and on time.
Joint prioritization is the basis for success in agile projects. It allows developers to deliver useful software as quickly as possible.
User stories will allow you to understand the user better and thus make you deliver software that meets their needs.
Otherwise, implementing the software makes no sense. Every business, including digital businesses, should prioritize the customer/user.