Hi,
Currently we run our projects where we have User Stories and Acceptance criteria in Confluence, and Jira tickets are used to organise the implementation of these via Sprints and agile boards (and to log time via Tempo).
We're finding that:
We've started to do the following, in an effort to mitigate some of these issues:
This solves a lot of these problems however after some research I've found that a lot of places are doing the opposite of what we're doing where Confluence is used as just a list of User Story titles and have a link to a Jira ticket that has all of the meat (User Story, AC, status, conversation). There's even a blueprint in Confluence that drafts this (Product Requirements) for us.
I actually think this approach is better, but wanted to see what others are doing and how they find it?
Some issues with this approach that I haven't solved for yet:
Keen for any insights from anyone.
Cheers.
Hi @seesomethingelse
For context, I work at a larger financial enterprise organization with 85,000+ employees.
I've witnessed a number of different teams using either Confluence or JIRA to contain the "meat" of the user story and personally I haven't yet identified if one or the other is a "best practice". Generally speaking, I've seen many teams operate in the manner you are describing:
The teams I have been working on most recently have been operating the other way around, where PO/BA creates a Confluence page with their requested Product feature (EPIC), high-level requirements (acceptance criteria), a table of user story titles with short summaries and links to the corresponding JIRA issues which contain the "meat" of the story including a Summary, Pre/Post Conditions, Business Rules, Mock-Ups, Translations, Links to other Confluence pages with details relevant to the conversation, etc...
When requirements change to a particular feature or US after the previous JIRA ticket was closed, we simply open a new JIRA ticket to capture what needs to change moving forward.
Regarding best practices...I believe the best approach will depend on what goals you are trying to achieve.
Are you trying to capture all the relevant details of your conversations related to a particular product feature?
Are you attempting to leverage Confluence as living documentation for your product on an on-going basis? ie, You want to know about a particular product feature and all the different work that has been done or is currently being done on this feature over time?
Are you using Confluence to manage requirements related to a future release?
Regarding your questions:
I'm also interested to hear from others regarding this topic to understand what strategies they use and identify any tips or best practices they implement to handle the challenges mentioned by the OP.
To me, it's not only about the team deciding on who is the quarterback, 'system of record', or source of truth like the original person posted. But, most importantly, where is the best place for the BA (and Tester if you pick a requirements tool that can also provide for test case creation, runs, and traceability back to the user stories (or requirements.) I work on short projects and large projects and often get paid for producing good deliverables. If your story system of record cannot quickly generate deliverables and cannot keep versions of the stories from creation to baselined, you are already behind.
Our approach is to use Jama Contour as the 'system of record' and when baselined by the customer, we synch the stories to JIRA. The dev team takes over from there, plans their sprints, adds subtasks or whatever work needs to happen in order to move the story through the development and ultimately test process. I have one team where the customer forced our BA's to use JIRA for management of user stories, and wait for it, Excel spreadsheets for test cases. Generating deliverables is a nightmare. Tracking numbers is worse. And, the team spends more time performing herculean tasks to produce anything or conduct any reviews where are other teams get things done in record time.
Something to think about for newbies making tool selections. Let JIRA do what it does well. Pick another tool to help the front end side of a project. Trust me. You won't regret it.
This thread fills me with horror. What happened to the good old days of agile principles like stories being a placeholder for a conversation, working software over comprehensive documentation, customer collaboration over contract negotiation. Before Jira and Confluence we wrote story outlines and a bullet list of ac's on a record card which was thrown away at sprint end.
What perceived problem or user need is being solved here?
Simpler times.
Recommended Learning For You
Level up your skills with Atlassian learning
Learning Path
Apply agile practices
Transform how you manage your work with agile practices, including kanban and scrum frameworks.
Learning Path
Configure agile boards for Jira projects
Learn how to create and configure agile Jira boards so you can plan, prioritize, and estimate upcoming work.
Jira Essentials with Agile Mindset
Suitable for beginners, this live instructor-led full-day course will set up your whole team to understand how to use Jira with an agile methodology.