Is Jira not good enough to manage requirements?
The structure of requirements is not an easy topic. It involves not only organizing all the information but also enabling the reuse of requirements, their easy maintenance in an up-to-date state, and a quick understanding of the connections between requirements.
Let’s talk about why, in my opinion, platforms like Jira and Azure DevOps are not suitable for managing requirements.
- The necessity of closing epics to track development progress prevents maintaining requirements and having a holistic view of them.
This means that if we receive new requirements or changes after closing an epic or feature, we cannot modify it or add new user stories to it. In other words, if we have a diagram or some logic described in the Jira Feature and it changes, we cannot update it in a closed feature; we create a new one which results in the fact that we don’t have maintained requirements but just deltas without any understanding what is the final picture is.
As a result, everything contained in Jira usually has no use after development, demotivating analysts from maintaining requirements and keeping order.
Whereas, the analyst’s task is to keep the requirements up-to-date and comprehensive. Platforms which are determined to documentation management allow you to have One Feature on the one page in up-to-date state and track all versions you need.
2. Since this is a development-focused environment, you cannot establish all the rules for managing requirements on your own. You need to consider the developers’ convenience and their perspective on how they would like the requirements to be presented. So everything there is configured for them and their processes and tasks. Analyst processes and tasks are broader than just writing user stories and therefore require a separate tool as only a BA should decide what techniques are needed for the quality analysis.
3. There is no opportunity to keep other BA information besides functional requirements and build an effective requirements structure.
The Jira structure does not allow having separate general requirements or BA information, such as a Stakeholder List, Glossary, Business Rules, and high-level Artifacts that make up the product vision. It also doen’t assume to create requirements Templates. To do this, you need to use additional tools and store them somewhere on a separate portal, or, even worse, on the Business Analyst’s computer.
The development-focused environment limits you and ends up in the fact that BA uses not those techniques which help them to analyze deeply, but which are used by developers. Here I would like to emphasise the difference: BA needs to use techniques to immerse deeply in the topic and generate questions. Developers don’t need those intermediate artefacts but need the results of the analysis: User stories and Acceptance criteria.
Using such a development-focused environment like Jira, more often than not, boils down to the fact that BA skips the analysis process (there is no place to put, keep and maintain artefacts which helped to analyze) and specifies User story and Acceptance criteria only, what is too narrow perspective for the comprehensive requirements.
Thus, building a good requirements architecture that would facilitate the analyst’s work is almost impossible.
Whereas, the analyst’s task is to include all information about requirements at all levels in the requirements architecture.
4. Prevents constant access by all stakeholders to all Business Analysis artefacts.
This is a consequence of the previous point. Since many artefacts that were needed to analyze don’t find their place in Jira and are stored by the analyst on their computer, access to them is severely limited. The picture in Jira is too narrow.
