When working in an Agile team using the tools of the Atlassian suite and in particular Jira Software and Confluence, one of the questions that comes up most often is whether it is better to document user stories on one or the other of the two tools.
One thing is certain: documenting user stories in both tools is counterproductive. You would have to fill in the same information twice. And in case of a change, you must not forget to update both tools or you risk confusion for your team.
So which one to choose?
#Confluence Team to document its user stories
If you are a fan of organization
Confluence is an enterprise wiki and a content manager. It allows to define structured pages containing text, images, videos, mockups, ...
To document your features, Confluence offers a page template called "Product Features".
Working at the level of the functionality gives a common context to the user stories that make up the functionality.
We can thus define the version and the people involved in this functionality but also link it to an epic on the Jira side. The status of the document allows the team to know immediately if it is possible to work on this version of the document or if it is still a draft.
Then write the objectives, context and assumptions in a simple and straightforward way so that your team can easily understand them.
We can then translate the various functional requirements into Jira user stories. These are first described in Confluence and then created in Jira via the quick creation mechanism by selecting the user story title (see below).
The user story is thus created directly in Jira and a link is made to the Confluence page from which it was created. The context of the user story is thus easily accessible from there. This context can be structured as you wish by adding, for example, preliminary design information (mockups, screenshots, etc.).
All user stories and their states are thus visible from the Confluence page.
#Team Jira to document its user stories
If you prefer a little less structure
Jira is a work management tool that will store all the user stories, epics, tasks and subtasks of your project. For some teams, it can be annoying to have to switch from Jira to Confluence all the time when they are working on a particular user story. So these teams tend to work only with Jira and not Confluence at all. The user story therefore contains all the necessary and sufficient information for its implementation. The advantage is that we know at any time from the table (scrum or kanban) what state the user story is in. We can also know who is working on it at the moment and all the other information specific to the Jira request.
One of the problems with this approach is that, even if all the information is centralized directly in the user story, the structuring of this information is much less developed than in Confluence. We tend to fill in everything in the Description field. As a result, the user experience can be diminished if he has to go through a hundred lines of functional requirements. Jira does not allow to define a default value that would give a structure for the description before version 8.16 Data Center.
Atlassian allows administrators of Jira Data Center versions 8.16 to add contexts with a default value to different types of requests and projects (as can already be done with custom fields).
Nevertheless, you can create custom fields or use plugins to counter this problem. For example, we can define a list of acceptance conditions or create a priority field to implement the MoSCoW method (Must have, Should have, Could have, Won't have).
In conclusion
Confluence and Jira both have advantages and disadvantages for managing user stories. The main thing is to choose a method that best suits your team. If your team prefers to have well-structured requirements with complete information, go with Confluence. You will then make the link to the user stories created in Jira. If they don't want to switch from one tool to another and want to have all the information centralized in one place, even if it's a little less well structured, go with Jira alone.
