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 an on-premises, 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
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
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.