Let's be honest: the emphasis on Agile has led to a backlash against requirements and test coverage and, overall, against the Software Development Life Cycle (SDLC). The principle of "working software over comprehensive documentation" resulted in the marginalization and neglect of requirements management. As a discipline focused on describing the product or system, requirements management was sidelined, with greater attention placed on enabling developers to work at high velocity.
SDLC has become synonymous with waterfall. Agile teams believed they did not want or need a proper SDLC.
While the industry has focused on velocity, our customers expect us to deliver new features without compromising quality; they do not want to choose between the two. For instance, on July 19, 2024, millions of passengers experienced flight cancellations due to a failure of the CrowdStrike Falcon Sensor. These customers would have preferred that CrowdStrike had a more effective software development life cycle (SDLC) process in place. Endpoint security is just one critical area where we need to ensure both high adaptability and reliability, even though it is not as heavily regulated as industries like pharmaceuticals or avionics.
To achieve speed without compromising quality, we must adopt a more holistic approach that encompasses the entire Software Development Life Cycle. (SDLC). And no, let's not confuse SDLC with Waterfall.
In designing more adaptable Software Development Life Cycles (SDLCs) suitable for an agile environment, I draw inspiration from several current trends: First, DevOps practices must integrate product teams and the SDLC. DevOps emphasizes cross-disciplinary collaboration and automation, which are foundational to creating streamlined SDLCs. Additionally, the concepts of organizational agility, particularly those from Team Topologies, provide us with a beneficial framework and vocabulary.
Requirements are distinct from stories and epics; they are not development tasks
In the effort to minimize documentation and paperwork, teams have overlooked an important point: Jira stories describe the work that we need to complete, not the product or system itself. To determine whether a deployment is successful, we must understand the requirements of the deployed system. Therefore, it is essential to clarify what those requirements are.
For example, this is a typical requirement for a banking system:
Requirement 
Key: EBANK-63
Summary: Copies of documents used during new customer onboarding (for KYC verification), will be stored in an approved electronic form
This requirement governed the banking system when it was first created. It remains valid today, even after five years and numerous updates. However, it is not part of any of the recent stories or epics.
Looking ahead, the bank plans to upgrade its document scanning module in the upcoming product increment. To ensure that the new module scans to an approved format, we need to identify what these approved formats are. If we lack proper documentation, how can we verify this? Furthermore, how can we guarantee that the new system will meet the requirement if we do not have a regression test in place?
Requirements serve as the foundation, outlining how the product or system should function. An effective regression test suite can verify that it does.
We configure stories and epics to optimize how our teams work. We cannot overload them with other intentions or needs without compromising their raison d'etre.
Dynamic Requirements Handling for Agile Teams
Separating requirement work items from development work in Jira provides several benefits:
-
Optimizing requirement work items for product specifications (rather than instructions for developers). For example, the summary and description field can use 'requirements' language, not Story language. Also, the split into individual requirements will not be disturbed by product architecture or team structure considerations.
-
Creating a workflow that enhances the productivity of product teams.
-
Simplifying epics and stories, avoiding bloated workflows and boards.
-
Respecting the cognitive limits of all individuals involved, including product managers, business analysts, project managers, developers, and testers. For example- not getting product owners into the weeds of the development flow.
When designing the Jira configurations for requirements, consider the following aspects:
-
Do you have a hierarchy of requirement types? For example, work item fields and workflow may be different between User Requirements and functional specifications.
-
Use the fields and custom fields that you need and remove those you do not need. For example, add a 'Requirement category' field and remove the development panel. Also- consider the semantics of fields. For example- will you use the fix versions field, and how? How will you know which versions of your product are fulfilling this requirement?
-
Tailor the workflow to the specific needs of product teams. The done status for a requirement is that it is part of the product.
-
Include a review status by the product owner in the Definition Of Done for stories. This step will be the control point to ensure the implementation meets the needs.
-
Automate the handover processes between the Story workflow and the requirements workflow. Here are some areas of handover: When does a requirement create a story? When the story is complete, does it impact the status of the requirement?
-
Clearly define how requirements that are already in the system can be updated.
-
In Xray, ensure that requirements are considered coverable items. This will allow product teams to see directly the status of test coverage for each requirement.
.png?cb=338831cc759983e66b916516e8474ef8)
Here are video demos of the Jira configuration:
Test management for agile teams
Agile teams aim to integrate testing efforts into their development sprints. But what does this mean in practice?
2 Want a rapid SDLC? Manage testing directly inside Jira
3 Integrate test automation with SDLC
Testing is multi-layered, ranging from code reviews and unit tests to User Acceptance Tests. The testing process begins as soon as a User Story is groomed for the Sprint and continues even after the story achieves the Definition of Done. To better understand how to integrate testing with the development Sprint, it's helpful to look at distinct types of test activities.
|
Test activity |
Organization in Jira |
|---|---|
|
Story-level tests are crucial as they feed into the Definition of Done. This is where close collaboration between developers and test engineers is essential. The key activities are:
|
Test executions or sub-test executions are created for each story in the Sprint. This allows testers to assess the scope of testing, create new tests, or update existing ones even before development work on the story is ready to be tested. |
|
Other testing tasks, such as regression, security, and performance testing, are also included in the Sprint. However, these tasks are not part of the "definition of done" and may be part of a later Sprint. These tasks include:
|
|
|
User Acceptance Tests (UAT) |
UATs are typically conducted separately from the Development Sprint and are owned by product managers. |
Conclusion
Requirements and test management add additional work items to Jira and necessitate a configuration beyond the Sprint board. This is not busy work created for the sake of formality; rather, it reflects tasks that already exist. By establishing a Software Development Life Cycle (SDLC), these tasks can be explicitly outlined and managed as part of your organizational workflow. This approach also helps in delivering better systems.
I hope this article has provided you with insights on how to effectively manage this flow in Jira.