Elevating Software Quality by Overcoming “Unclear Requirements”
Software quality begins with the quality of the requirements.
- Pearl Zhu
This post describes how we have improved the quality of the product requirements by introducing standardization to a common form of requirements in Agile, Epics and User Stories.
Understanding Unclear Requirements
I joined JULO as a QA Lead towards the end of Q2 2022. My one and a half decades of experience in QA as well as taking the PO (Product Owner) role had given me exposures to working on requirements, both creating as well as analyzing them. And that experience fortunately became useful in solving the very first problem that I discovered early at this new job.
During my initial days at JULO, the most common topic of the discussions among my fellow squad members was unclear requirements and how it was impacting the overall quality of the product.
With this situation in hand, it reminded me of a principle — “A better quality product is always delivered by a team who understands the requirements clearly”.
In the pursue of finding solution for this, I did further analysis and figured out that the requirements were not clear because of the following factors:
- Big requirements were not divided into smaller ones.
- Requirements did not speak about — who is the user, what is the purpose, and what will be achieved by implementing those.
- No specific validation points defined to confirm that requirement implementation is successful
And this was resulting in
- Multiple back and forth discussions between the Engineering team & the POs to clarify the queries.
- Not-tracked discussions so in case anyone was not involved in any discussion there was maximum chance of missing the required information.
- At the end it was impacting on the product quality i.e. bug leakages.
Solution: Structured Epics & User Stories
Based on my prior experience of working on the requirements, I was aware of the usefulness of the structured Epics & User Stories. To overcome the current challenge, my initiative was to create a standard template for both of them.
And the expected outcome was in terms of
- Well classification of big & small requirements.
- Traceability of the requirements i.e. small requirements (User Stories) are part of the big requirements (Epic).
- A clear understanding on who exactly is interacting with the product (actor), what the user needs to do (action) & what the end result should be achieved.
- Well defined acceptance criteria, which will act as clear validation points both for unit testing and also QA testing.
The following articles were used to recollect my understanding of Epics & User Stories in more detail.
- Epics | Atlassian
- Definition of Done
- How to Add Acceptance Criteria to User Story
- User stories: Why is it Important to Agile? — Agile Scrum
Epics & User Stories in High Level
How We Approached this Initiative
Initial Discussions
With the solution proposal in my mind, I approached the Head of the Engineering and also the Lead Scrum Master of the organisation for further discussions. The aim was to create clearly defined templates along with a section on acceptance criteria.
After subsequent multiple iterations of discussion & reviews, we came up with the following strategies:
- Defining big chunk of requirements as Epics
- Creating templates for Epics with well defined details
- Mapping Epics to respective user stories
- Creating templates for User stories
- Creating guidelines on how to write User Stories & Epics
We created the template for the Epics.
And similarly, we created the same for the User Stories.
Guidelines for creating Epics & User Stories
After finalizing the strategy, we created a written guideline on how to create User Stories & Epics so that POs can refer to it in the future. We also updated the Epic & User Story templates on Jira card’s description so that each time POs creates a new one, they will be reminded of the required fields and also will be easy for them to fill in.
Pilot Activity
After the approach & the templates were finalized, we started the pilot activity in one of the squads that I was working with.
The POs were explained about the overall concept and were requested to prepare the epics & user stories in accordance. We also involved the Development & QA team members so that they can evaluate it from their perspectives.
The pilot activity was carried over for more than 2 sprints and during this we collected multiple queries, both concerns and positive feedback from the participants.
During the retrospective, we got multiple positive response on this initiative. There was also a feedback that it was taking longer for the POs to create the items as compared to earlier; however, everyone opined in unison that the benefit was much bigger than the downside and so all showed eagerness to continue with it.
Socialization
After the successful pilot activity, we socialized it with all the squad POs and also to the scrum masters.
All the scrum masters were requested to monitor & also to guide in case any squad POs needed assistance in creating user stories/ Epics in the newly defined templates.
As a result of this, currently “Epics & User stories template standardization” is running as a process at organisational level and every squad now follows this.
Results
This initiative helped each of the members involved in the software development activity in the following manners.
Product Owners
- Easy to write & elaborate on the requirements
- Clearer to define acceptance criteria
- Minimized the risk of incorrect verbal explanations
- Better management of expected outcomes
Developers
- Clarity on what to be developed and pointers for unit testing
- Well enough detail helps to understand requirements more clearly
- Acceptance criteria help developers to build the technical approach better.
QAs
- Acceptance criteria help in defining clear test cases
- Having consistent and detailed requirements help in analyzing the requirements more clearly
- More edge case scenarios are covered
- It helped to improve overall product quality
Scrum Masters
- Reduced overall time consumed in Product Backlog Refinement & Sprint Planning meetings
Testimonials
Here are a few testimonials from implementing this approach:
“Developers got benefited :Now Developers become more alert , so if the User Story is empty then it is most likely not going to be considered to be taken into account during Sprint Planning.” — Scrum Master
“I like the additional requirement part (like an additional requirement of the acceptance criteria), this helps the developer build the technical approach better.” — Developer
“Developers have more clarity to focus on based on acceptance criteria and helping them to define a case list for creating unit test” — Tech Lead
“The initiative helps to simplify the explanation for the card’s intention. User story is simpler to write compared to background” — Product Owner
“QA now has more ideas for creating cases from acceptance criteria and do try to think of more edge cases from there as well. Maybe sometimes the acceptance criteria come up with more questions but which is good so we can have more clarity from points on acceptance criteria” — Jr. QA Lead
“I don’t have the exact numbers but I can say the refinement and sprint planning meetings in my squads are shorter than it were.. including the time needed to estimate the story points and do the poker planning. with the clear cards, they seem to already know what to do just by reading it, no need for long explanation/clarification from the PO” — Lead Scrum Master
“Simpler way of explaining what we ACTUALLY want in the form of acceptance criteria. This minimizes the risk of wrong explanations on the description part. Manage expectation better.” — Product Owner
“So much easier for me to define the acceptance criteria and requirement that is needed due to the new template that is already there. Quick and direct explanation makes it way easier on reading efforts.” — Product Owner
Conclusion
Out of this whole activity, again I myself learned a few new things so I’d like to share here in hope that these can be useful to others.
- Requirements are the foundation of any software development process so each member of the team needs to have a clear understanding of it.
- The clearer it is during the creation process, the less difficult it becomes to explain later.
- A standard template is always helpful so that the entire organisation can use a single process.
- The approach of having initial discussions with a small group, piloting the initiative to one of the teams to gather inputs, and then socialising it with clear and polished guidelines have proven to be effective in an Agile environment.
Unclear requirements is now hardly a conversation with the teams! Topics of discussion have now shifted, meaning we’re moving on to tackling other problems. Stay tuned, many more improvement initiatives on the way. 😀
Thank you for reading everyone!
