Clear Requirements Absence in User Story: Lack of Time or Laziness?
Only one out of five teams I worked with had properly written user stories with a requirement list.
The rest of the user stories had just plain text in the document with poor description.
Depending on the type of project you work on it can be applied one of the approaches. In terms of startup delivery speed, the short description is a more convenient way. When the product gets bigger it is better to have detailed documentation. Not exhaustive one, as we all know it is hard to maintain documentation and keep it up to date.
Another case when the Project Manager describes several epics/user stories on a very high level is when it needs to have a general representation of a business value. In order to have more precise product delivery estimates, development and QA teams should get answers to questions they might have.
It is pure art to create laconic and yet informative user stories with clear requirements. Why is so important to have it and why this rule is often neglected we will consider in this article.
A Proper Requirements List Benefits
One of the benefits of having a requirements list is to avoid user story unclarity by team members. For QA engineers it is extremely helpful when it comes to the test design analysis and implementing test cases. It can be:
- bullet list format;
- given-when-then format;
- other format.
No matter what format you choose, it should have the expected result. That way, QA Engineers will get full requirements coverage in their test cases. In order to get a comprehensive view, it would be nice to have a linking mechanism on each Agile structure level.
For “Epic” level join a user story to the test suite.
For “User story” level join a requirement to the test case.
Traceability matrix is one of the ways to represent these levels.
User story 4 and 6 in the first table doesn’t have own test suite to cover. The rest user stories have been covered with test suites.
Requirements 5–7 in the second table don’t have their own test cases yet. The rest requirements have been covered with test cases.
Poor User Story Description
What will happen if we don’t clarify requirements before the development process?
Consequences of neglecting clear requirements:
- silly defects;
- unclarified requirements;
- change requests in the middle of the sprint;
- workarounds;
- backlog stuffed by additional tasks we could avert.
And as result we get:
- postponed release;
- tech debt;
- development and testing cost increase;
- etc.
Walkthrough meetings with PM, Developers, and other QA engineers helps us to avoid these problems at the very beginning. It won’t take away all the problems, but it will be significantly decreased simply because we found implicit cases by using communication and test analysis (that couldn’t be revealed other way). Such prevention mitigates severe risks that might occur at later stages of SDLC and STLC.
Summary
It is a good practice to pass through user story requirements together, so everyone (PM, Designers, QA engineers, and Developers) has a clear understanding of how the feature should work. And only then start the development process.
I know, in reality, we have a completely different picture. No one eats breakfast in a calm atmosphere, everyone is in rush and eats his sandwich on a go. The effort you put at the beginning pays off. At least it worked for me when I was able to apply test design techniques and had a solid conversation with developers. Win-win! Only one bug was missed at the time I was testing the feature. And that was the power of efficient communication and test design.
QA engineers can review test cases with all team members who are interested. Even if we have some questions in the comments to a document or whatever source of communication you have on your project, it is highly recommended to have one place where you can find all requirements (the single source of truth).
From my experience, we cannot avoid all minor issues or improvements here and there. However, fixes often take a lot of time and may cause problems in the affected area. It is all about priorities because we have deadlines. Hence, we are forced to close our eyes on minor issues.
The early communication in the team can eliminate some of the issues or uncovered scenarios and unrevealed requirements. Developers have the opportunity to write the code in a more efficient way. QA engineers have fewer headaches during the verification process.
Even when managers are out of time, QA engineers can assist with putting all requirements into one place.
Let me know, how detailed do you describe user stories? What tool do you use to manage information obtained from different sources? Any struggles with linking requirements with test cases and maintaining test documentation up to date?
