“Build the perfect product and make it right.”
This is a common goal for many engineering teams. But how do we accomplish this?
It has two parts. Building the right product and building it correctly. Let’s begin by dissecting the problem and focusing on the first part: building the right product.
Quality analysts are often able to bridge that gap and promote building the right product, which in turn increases productivity. We would need to analyze the requirements with the QA in view.
Visualization of the workflow: Analysis with Quality Assurance includes Requirement Analysis
In Quality Foundations, we’ve discussed a great user story. We also discussed the meaning of the story being available for download in Definition Of Ready, which is a concept that can guide us on our journey to better requirements. Let’s now take a closer look at what requirement analysis is and why it’s so useful.
Disclaimer: This may not work for all teams – it’s possible that a team might not want to conduct a detailed requirement analysis.
What is requirement analysis?
Requirement analysis involves the study, feedback and, if necessary, the modification of the product’s expectations.
Who should be involved?
For the first round in requirement analysis, I recommend that you prepare the stories using the Three Amigos approach.
Three Amigos – This is a way where the business analyst (who wrote it) meets the quality analyst and the developer to discuss the requirements. They work together to analyze the story.
If design decisions were made, some of the teams I have worked with also had a designer. You will involve the entire team in the presentation of the story during the final stages. (Read more below about this).
Why is it important to conduct requirement analysis?
Isn’t it enough that the business analyst wrote this story? But people make mistakes. The product is not perfect and no one in the team has all the answers. Collaboration is key to a successful product. It is important to have well-analyzed requirements.
- Technically, the product requirements can be met
Multiple cases have been presented to me where developers were involved in the story. They spent a lot of time and effort to get to the core functionality, but it was impossible to implement. This led to a lot of rework both on the engineering and product sides.
- We create the product quicker and with better quality
The requirements must be clear and the edge cases that have been discovered are explained. If it’s technically possible, then the team will have a lot less “pingpong” games with the product. We avoid misunderstandings and bugs by making sure everyone is clear about what they are building.
- The team is held more accountable for the product
Team members who are aware of the product they are building will feel more accountable and caring. Team members are motivated to do their best by being on a mission of building a great product.
Okay, but what makes it any different than just having a story refinement meeting?
A grooming or refinement session for user stories may be in place. This is where the business analyst presents work items to the team and requests feedback. These meetings can be a waste of time if the stories do not match well-analyzed requirements.
The whole team can participate in story refinement sessions. These sessions are extremely useful when done correctly, but they can often involve way too many people in too short a time. We should be prepared to respect everyone’s time and bring all necessary tools. The prior refinement session is a great way to get QA and a designer involved in the requirement analysis.
My worst refinement sessions did not include user stories. This was product documentation. It was just product documentation. Most developers couldn’t even understand what it meant for them. Everyone would be able to understand the user stories if they were presented instead. Additionally, user stories that have been analyzed before will likely result in fewer questions and comments. The team will also be able to gain deeper insights and not only point out trivial gaps, but it can also save time and help us develop faster.
Isn’t it a waterfall if most requirements must be clear?
A common misconception about agile work is that it is ad-hoc and doesn’t have any planning. However, it does have planning! There are always chances for things to change.
When I speak about requirement analysis, I refer to a small piece of work like a user story. This is already a small amount of work that can be released, and it’s likely that it won’t take too long to complete. The requirements should be prepared before we pick it up. This will ensure success. This is a small part of the project, and not the entire plan.
How do you conduct a requirement analysis?
As a first step, I recommend that you start with a small group to review the requirements.
This is not the case in many companies. Although it may sound strange, let me share my experiences and show you how it can be helpful.
As a QA, I am closely involved with business analysts. I often share the user story with them. Sometimes, we would also pair writing acceptance criteria together.
Tip: You can do this even asynchronously. Ask the business analyst to tell the user story after they have written it.
The main part is now. Questions! It will depend on your context and knowledge of the domain, but these questions are what I am asking myself when it comes requirement analysis.
1. Are the acceptance criteria clearly defined?
2. What might be misunderstood about the phrasing?
3. Does the story cover both positive and unfavorable paths? Do you think there are any other paths that could be described?
4. Do you have to add tests or monitoring as part of the user story?
5. Is the user story available and can it be tested on its own?
This question focuses on slicing. Good slicing means that a user story can be released by itself, and this is what we are aiming at.
6. What are our success indicators?
7. Is it technically possible? Do tech notes need to be included?
8. Do you have dependencies with other teams? What do we need to get from them if there are?
9. Are the design mocks complete (for now), clear and attached to the user story
10. Is it possible to identify the motivation behind this story’s creation? Do we know who the main character is?
There are many other questions you can ask. You can find more ideas in my article with Steve Upton, Asking questions for.
It can be difficult to discuss requirements. Quality analysts might bring in many edge cases and quality demands. Developers might also be involved in a lot tech work. Developers may also be responsible for a lot of technical work. Respectful discussions are important to determine the risks and tradeoffs that you are willing to accept.
This video is a great way to learn more about The Business Value of Quality by Finn Lorbeer, Nina Hillekum.
After you have completed your requirement analysis, you should ask yourself: Are we meeting our Definition for Ready? Congratulations if yes! You have likely written a user story that will make development easier.
Storytime: The importance of requirements analysis
How did I discover the importance of requirement analysis and how can I help others? Let me tell you about a story. I was very new to the idea of working with business analysts. I joined a team recently and was eager to get started. It was a great idea to prevent defects. But how can you do that in practice?
My business analyst and I sat down together to review the user story they had written. The result was an hour (!!!) of discussion. This led to a long discussion about one sentence. The acceptance criteria was “The user logs into …”. It sounds simple, right? It sounds simple, right?
For example, you could log in to your Google account. Log in as admin. To log in, you could use your basic credentials. You could also log in using the website’s account.
It was obvious to the business analyst when they wrote it: “Officially, you log in with the website account!”
Even though we had a lengthy discussion, we ultimately decided to leave the way it was written. Maybe I shouldn’t “nitpick (the professional disease of QAs, not? ).
The developers created a login using their credentials. It wasn’t clear and it was technically impossible to do so. It was not clear and it was technically impossible to do it differently.
Example of requirement analysis
Imagine that the analyst from business shares your story with you.
The first user story
Is this a great user story? Why?
It’s not a great user story, I think. This article raises too many questions in my head.
Example of asking the user story about their first use
We can then sit down with the business analyst to create a better user story (it may be familiar since it is included in the article which explains different types of work item types).
Improved user story
The story could use more details. “Thorough Monitoring” isn’t descriptive enough. It is possible to specify the metrics that we would like to track or the dashboard that we expect to see following implementation.
Let’s take a look at another questioning scenario. This is how you might feel if you were to get the following requirement:
We want to keep the information of new users in a separate user storage when they are created.
What would you like to ask?
This is what I would like to know:
Example of questioning a requirement
In a Nutshell: Requirement Analysis
In a nutshell, this is the requirement analysis:
- You can also rephrase
You don’t have to know the answers to the questions. It is likely that someone on the team has an answer. What you do is Advocate for building a high-quality product. All the points discussed matter: testing, cross functional requirements or phrasing.
A well-done requirement analysis saves so much time. It may seem that it adds extra work in the short-term. You need to collaborate, clarify, raise all your concerns and make sure you are clear. We will grow so much quicker if we avoid rework or misunderstandings.