Jira Magic: Transforming Product and Engineering handovers in Agile SDLC

[#1]

Delivering value to customers often requires collaboration across various organizational units, teams, and timeframes. One of the advantages of managing all aspects of the value flow in Jira is that the handovers between tasks and teams become explicit, are carefully considered, and are intentionally designed within the system. When separate teams own different work items, we can view the integration between the workflows of the two work items as a contractual agreement between those teams—defining how their collaboration will function.

I am sharing a use case that illustrates a single value stream within an Agile Software Development Life Cycle (SDLC). This flow outlines the process required to take a prioritized requirement and transform it into a part of the product, preparing it for User Acceptance Testing (UAT).

Achieving a Seamless Flow Between Product and Engineering in Agile SDLC

Here is how Product and Engineering teams interact to bring new requirements into the product:

1. The product team takes a requirement idea and develops it into a fully fleshed-out requirement. At this stage, the expectations and scope of these requirements are defined and endorsed by the business. Additionally, Product holds discussions with Engineering regarding feasibility and implementation. This process occurs in the Product Space, utilizing a requirement work item. Once the requirement is defined, the Product team hands it over by creating one or more stories in the Engineering Space unless a story already exists. The requirement work item is linked to the story using a link of custom type "Implementation."
2. The Engineering team may adapt the story to better suit their needs. They may rephrase it, break it down in different ways, or even delete it altogether. For instance, if another story already addresses the requirement, the new story is removed, and the existing story is linked to the requirement. The links to the requirements are updated, ensuring the Product team is always in sync.
3. During the implementation of a story, developers and software quality assurance teams work together to ensure that the implementation functions correctly. Before the story is complete, the Product team reviews it.
4. Other testing activities, such as updating performance tests or executing regression tests, are not included in the Definition of Done for a story. However, they do impact the test coverage of the requirement. SQA engineers link the requirement directly to the various tests that cover it. This practice serves two essential purposes: first, it helps product teams and SQA understand which tests correspond to a requirement, and second, it eliminates false flags and unnecessary complexity in test coverage (potential results of linking to tests only through the stories). This is particularly important as a large product evolves and goes through multiple stories and iterations.
5. Once the Story is complete, the Requirements work item can move forward into ready for User Acceptance Testing (UAT).

Jira Configuration for a Streamlined Flow

To support this workflow, the Jira configuration must assist the team in maintaining situational awareness, guiding their next steps, providing guardrails, reducing manual work, and avoiding any obstacles. That's a lot to ask!

Let's examine the specific configurations that drive the interactions between Product and Engineering:

Point 1 in the diagram: The handover from Product to Engineering. Although we could automate the creation of the Story, we have chosen to keep this as a manual process. The reason for this is that Product and Engineering often discuss the requirement before the handover. That discussion typically leads to the manual creation of the stories.

We want to ensure that a Requirement can't be moved to "IN DEVELOPMENT" unless it's linked to a story. This rule helps our team follow the workflow we've set up. It's a configuration of a condition on the workflow. For information, this isn't a built-in feature in Jira, so we'll need to use an extra app like JMWE to make it happen.

There will be instances where a change in requirements does not necessitate the creation of a new story. For example, if a requirement is modified in a manner that does not impact the product, the workflow should allow a direct transition to User Acceptance Testing (UAT). In such cases, the Product team must justify the change. This can be implemented by configuring a custom field for justification in Jira and adding it to a screen, along with a validator on the workflow transition.

Point 2 in the diagram: After the development work is completed, a story cannot be marked as "DONE" until it passes through the "Product Review" status. At this stage, the story is automatically assigned to the product owner, who is the only person authorized to move the story to "DONE."

To achieve the change in assignment when the story enters "Review by roduct", use either a post function on the workflow or Jira automation. The post function can use a Jira field that specifies the "product owner" for the story or a project role. Implementing this behavior as a post function requires an app, such as JMWE. Discover how to achieve a similar behavior through Jira automation. ( https://support.atlassian.com/jira/kb/jira-automation-rule-to-auto-assign-issues-based-on-role-or-group/ ).

To ensure that only Product team can move the story forward, set a condition for the transition. For instance, apply a condition that allows only users in the Project role of "Product Team" to make the transition.

Point 3 in the diagram: To close the loop on the requirement work item, when the Product team reviews the Story and moves forward, Jira will automatically attempt to advance the requirement item as well. This can be implemented either through a post-function (which requires an app) or through Jira automation. Proper configuration will also ensure that the Requirement issue cannot transition to the next status unless all conditions for that transition are met.

For instance, if multiple stories implement a requirement, each story attempts to transition the requirement to the next status. This is done through a post function or an automation triggered by the story's transition. However, the requirement will only move forward when the last story is DONE. A condition is configured on the requirement to prevent any transitions until all stories are Done. This condition also requires an app, such as JMWE.

Tips and follow-up notes:

In summary, teams that interact with each other will significantly benefit from using Jira together. For software development life cycle (SDLC) processes, this approach can facilitate better collaboration between Product and Agile engineering teams.

1. You may need to use additional apps to enhance your workflow configuration or take advantage of Jira automation. When selecting an app, a comprehensive workflow extension App (like JMWE or similar) should be sufficient to address all your specific requirements.
   
2. Interested to learn more about SDLC in Atlassian? Read on about it in my series: "Ready for an SDLC shakeup? The good, the bad, and the ugly of managing requirements and tests in Atlassian"