Knowledge Base

 View Only

Move Away from Big Releases to Become Truly Epic

By Preston Mitchell posted 12-12-2016 20:15


Recently, I worked with with a long-time Jama customer that, years ago, created a complex system involving hardware and software which completely transformed how online retailers manage and distribute the millions of things we order every day. Jama facilitates the requirements and test management for this system.

This particular customer was undergoing a critical architecture shift from a self-hosted, wholly-released system to a service-oriented architecture. What was once a large, monolithic system that had big-bang releases is now becoming a distributed solution made up of many independent services.

At the same time, there was also a big organizational push to implement Agile methodologies on the software delivery teams. This architecture and methodology shift has many benefits – it lowers the risk involved with big releases, allows teams to deliver value to customers more frequently, and enables their solution to be delivered in the cloud rather than heavy and expensive on-premises servers at each customer site.

My goal for visiting this customer was to determine how Jama could help in this challenging shift to a new paradigm which really impacts the way they think about requirements and test management.

The Current State
This customer primarily uses Jama to:

  • Draft, review, approve functional specifications (system requirements)
  • Create traceability of functional specs to test cases to ensure test coverage
  • Execute tests and report test cycle progress

The Challenge
In the past, the customer had a large engineering team all marching toward the same release date. Now, many Agile teams iterate and deploy their services independently.

For the system engineers, their requirements typically need many agile teams across different services to completely implement a new feature requirement. The system and software engineers authoring the functional specifications have no connection or visibility to the Agile team-level user stories, so it’s very hard to tell the team dependencies and when the overall functional spec can be considered “done."

As we dug in with the Agile teams, we learned that many simply had a flat list of user stories on a backlog and no real hierarchy or traceability to requirements. These stories lived in a variety of Dev tools – some home-grown, some industry-popular tools like Jira.

The Recommendation: It’s Epic!
Jama recommended introducing an "epic" workflow in the requirements traceability model. Epics are basically a large user story that will be specific to an Agile team and tie together system requirements and user stories for each independent service. They break down the system requirements into something each Agile team can consume. Using Jama’s Integration Hub or Jama’s Rest API, these epics can sync to a variety of Dev tools each team prefers to use while Jama holds the roll-up and traceability to the holistic system solution. Agile teams decompose the epics to user stories on their Service backlog and as they proceed through their sprints, the epic status syncs back to Jama.



  • Create traceability between system requirements to user stories spread across several Agile teams and services
  • Allow business stakeholders to more quickly understand the development progress of system-level features
  • Understand what to test based on which System Requirements are holistically “done,” even though agile team services are released independently


The Takeaways
These recommendations aren't rocket science, they just require some time for teams to take a step back, analyze the challenge, and come up with a solution.

We understand it’s hard to pause the work of your job and think process improvement, but this proves invaluable time and again. One of the key principles of the Agile Manifesto is: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Are you looking to optimize your usage of Jama?
Is your team undergoing a methodology or architecture shift and not sure how to proceed with Jama? Connect with us; we would love to partner with your team for success. 

1 comment


12-26-2019 14:07

In our company we use an Agile process for development. We create user stories and detail them into functional requirements. Test cases are then added to each functional requirement.

The problem we have is that we are constantly changing existing functionality, with projects that can span 5 or more sprints. This means existing test cases that we use for smoke or regression testing which are linked to functional rules become invalid as the business analysts modify the existing rules.

Since there is no way (that I know of) to separate existing vs. new functionality by release and/or sprint in Jama, what is the best way to identify changes that will impact testing in 5 sprints from now vs existing functionality?

Developers keep their code separate by sprint by using branches which they then merge into the core (main) branch once any part of the project is ready for testing. However, QA and business analysts do not have this capability in Jama.

Any suggestions?