Approach to requirements in Confluence + JIRA

[Steven Battisti]

Hi all,

I think I double-posted this. Meant for it to be a question, not a discussion, although I guess it doesn't really matter which.

We're just about to start using confluence and jira for our SDLC, and we're trying to map out how this process will work the best. In our organization, normally we have product managers defining epics. Then product owners/analysts will take those epics and break them down into individual stories, which will then go through the normal life cycle.

What I'm thinking initially for our handling of this process in Atlassian is something like this:

1. Create a space in confluence for the requirements related to Product A. (No problem. Done.)
2. Product Managers create requirements pages in Product A, one page for each feature of Product A. So call it for now "Product A Home Page." 
3. Within the requirements page, Product Managers will document the high level requirements, with somewhere near the top of the page listing the overall feature name, e.g. "Product A Home Page". The requirements table below might have 5 high-level requirements underneath. They will then use the built-in Jira link functionality to link the place where it says "Product A Home Page" to a new Epic in JIRA.
4. In JIRA, the Epic will get assigned out to an analyst, who will review the epic and create stories from the requirements in the Epic as appropriate.

Does this flow in general sound doable? Am I going down a problematic road for some reason? Is there a better approach?

Ultimately we want a Confluence page for each feature that will always display the most up-to-date product requirements for all features. We also want the requirements to link easily to JIRA so that it's easy for people to get back and forth between individual JIRA stories or tickets and back to the overall requirements page / Epic.

(Considering adding Yogi to help with the integration.)

Like I said, brand spanking new to this, but if I can gain some lessons learned from people who have gone here BEFORE we screw it all up, that would be great!

Thanks!

[LeKisha Boswell · Accepted solution]

Your process seems very doable. I would suggest customizing a template for the Product Requirement page as to ensure consistency and to best capture data and elicit requirements that are most relevant to your team.

I would have BAs create user stories vs use cases (i.e., As a user I would like a large Pay button on the homepage of the website). Additionally, you might want to throughly plan what the nomenclatures of each page will be so that users can easily identify the content they are searching. Since your team will use the SDLC process you might want to try naming the pages as such Feature 1: Inception, Feature 1  Elaboration, Feature 1 Construction, Feature 1 Transition. 

Documents should be housed under each section accordingly:

• Inception (e.g., requirements/scoping, sign-offs etc)
• Elaboration (roadmap, architecture/design, risk register, sprint planning/meeting notes)
• Construction (development, testing info)
• Transition (user acceptance, retrospectives)

Of course information such as requirements can change at any step of the SDLC however the above will give stakeholders not only an improved understanding of expectations during each stage of the SDLC. Products Owners hopefully are deterred from adjusting the scope once the team is in the elaboration/construction phases. 

Link pages to issues will certainly help users navigate to the information they seek; however, when a JIRA issue is mentioned on a page an automatic link is created on the JIRA issue. Also, users can auto create JIRA issues from Confluence simply by highlighting plain text. This will help prevent double entry - once the PO agrees on the requirements the BA can convert them to user stories that will generate issues in JIRA. No worries if the user is already in JIRA, you can add a link to Confluence from JIRA by clicking the edit button on any issue, selecting "Link" and following the prompts.

Last as an added benefit to your team and leadership I would suggest using Tempo or another time tracking add-on to gather the cost of a project and to get better at estimating.