Our Process
User Story
Both Use Cases and User Stories refer to user requirements that describe what users will be able to do using a system.
Example of User Story
The Use Case could look like this: "Bookstore – update customer profile."
Meanwhile, the User Story would look like this: "As a customer, I want to update my profile so that future purchases will come to my new home address." It is important here to take into account that users have different needs.
We can see that User Story goes beyond indicating the user's goal, as it also describes its motivations.
Do you want to create a User Story?
Software: User Story vs. Acceptance testing
User Stories allow for Acceptance testing (related to acceptance criteria).
The purpose of the acceptance test is not to detect errors but to obtain confirmation of the execution of software of sufficient quality.
This is how we find out if we have been able to meet the requirements that the customer/stakeholder has set for us.
Testing takes place early in work, translating into satisfactory results, regardless of the methodology adopted.
The User Story relies on acceptance criteria rather than the written requirements to determine the details included in the User Story.
While testers will assess whether a requirement has been implemented correctly, they cannot tell what the customer/stakeholder will say about the software.
When we realize that a requirement needs to be changed, we must inform the business analyst.
Let's follow the defined process for the project to control changes which will give us a guarantee that changes will not be overlooked, and the impact of each of them will be analyzed.
But what if the subsequent User Stories are too big to be implemented in a single iteration? We divide them into smaller stories and implement each of these stories during separate iterations.
The user and his requirements. The problem with the initial assumptions of a project
Requirements are a specification of 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 Story, and Event-Response Tables.
User Requirements refer to the objectives or tasks that users will have to perform through the product.
Moreover, the requirements also refer to the description of product attributes or characteristics related to meeting users' needs.
To present user requirements, we can use, among other things, the User Story.
The User Story helps to establish the final priorities of the project, but they must be realistic because only then will they ensure the work's high effectiveness.
While doing so, let's remember how important the opinion of the development team is.
It is all about setting realistic goals, so pay attention when the team says that, for example, it is impossible to prepare a functionality in the requested time.
However, sometimes a project goes far beyond the initial assumptions.
Then we 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?
In order to identify the user's requirements, we should define together the tasks that the user has to perform with the software.
It is also important to choose the objectives he is trying to achieve. Requirements can be described not only with a User Story but also with Use Cases and Scenarios.
User Story, collecting requirements and iterations
When developing digital products, the work of collecting, analyzing, detailing, and updating requirements will occur throughout the solution design phase.
However, this does not change the possibility of the product owner coming to a conclusion 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 his key 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, we have 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 we 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 the requirements fit into the vision of the digital product. Then they are divided into so-called production iterations.
The division into iterations is worth doing in an intuitive way with the product owner, who will determine to what extent a particular functionality is essential to the usability and attractiveness of the solution.
We can also look at iterations as scopes of implementation. 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. This is done with the participation of the business owner.
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."
On the market, there are various variations of this method, such as the use of a three-point scale: "must be," "should be," "nice to have."
To assess prioritization, it will be useful to know the key competitive advantages of the designed digital product and key 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, we 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? We may have encountered a constantly dissatisfied malcontent, but it doesn't have to be the case.
The problem is rooted in the expectations gap, that is, the differences between what users actually need and what has been implemented.
Such a situation can occur, for example, when we place more importance on listening to the needs of a group of stakeholders who will not ultimately use the software.
It often happens when dealing with a digital product that some stakeholders want to meet their needs that are not necessarily in line with the product's vision, or in the course of conducting interviews, people with a more powerful voice demand the introduction of their specific guidelines.
We try to bend the functional requirements according to the outside, 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 and Scrum to the rescue
It is worth remembering this because we live in a dynamically changing world of business and technology, where continuous cooperation with the customer has become indispensable.
Hence, the growing popularity of MVP, design sprint, or Scrum. In other words, the agile methodology is gaining ground every year.
Agile methodology
The agile methodology was born in the '90s in Silicon Valley, although the name did not appear officially until 2001. At that time, the "Agile Manifesto" was published, 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, which is characterized by rigid patterns and a lack of flexibility in relation to changing customer needs.
Scrum vs. How does the user look at the project?
Scrum, an element of agile where User Stories are involved, is divided into sprints, i.e., stages of project 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 we receive information that the selected functionalities do not meet expectations at the end of a sprint, we can make adjustments in the next sprint. You can always quickly change a functionality for another one, or save money by abandoning an idea that did not work.
In Scrum, the product owner plays an important role. They create a list of needs for the sprint and present the work results to customers and users for feedback.
However, before the product owner takes action, his work is preceded by sprint planning. We limit the planning process to a maximum of eight hours if the sprint lasts a month.
We want to refer those interested in the topic to the book "Agile Estimating and Planning," written by Mike Cohn, one of the creators of Scrum.
It is 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 Story, 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 lead to a much smaller expectation gap at the end of the project, in addition to producing solutions that are much closer to the actual needs of the target customer.
Agile projects are characterized by the fact that the requirements management usually takes the form of User Stories in the requirements register.
During planning sessions, the product owner and the team agree on the stories that will be implemented in the next iteration.
In turn, such a set of stories is selected based on their priorities, as well as how efficient the development team turns out to be.
What happens next? Once a set of stories is selected and approved, they are "frozen," and the proposed changes to the requirements will be considered in future iterations.
Agile projects do not attempt to get stakeholders' approval of the full range of requirements upfront; in their case, the full set of functionalities emerges over time.
However, let's 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 is 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.
By having realistic priorities, we will be able to help developers produce maximum value at the lowest cost and in a timely manner.
Joint prioritization forms the basis for success in agile projects. This makes it possible for developers to deliver useful software as quickly as possible.
User stories will allow us to understand the user better and thus make us deliver software that meets their needs.
Otherwise, implementing the software makes absolutely no sense. Every business, including digital business, should put the customer/user first.