Advice on requirements / project breakdown

[paul bryant]

Hello

We are about to start a new project where we will be using Confluence and Jira to support a large mixed (Infrastructure & Software) system development. The organisation is a large traditional waterfall  system engineering business, and this is its first foray into the agile world. But we have been using Jira for some time for issue management.

We are going to use confluence as a wiki  / repository for all of the high level sources of information and then the generated  high level requirements from the information sources.

At that point those requirements would be transferred to Jira to a) derived sub-system requirements and then b)  manage the delivery of the products that meet the derived requirements using scrum.

I require some advice as to which way go for the Jira part. Do we create one project to do both requirements and delivery or do we create two projects one to derive the requirements and the other to deliver the products?

My concerns are if we use a single project how do we separate out requirement work from product work given the limited levels of hierarchy and maintain traceability back to up through the requirement tree..

Whereas if we use two projects  how do I transfer over the derived requirements and also maintain linking back confluence for context. and requirement traceaability

Many Thanks

[Tarun Sapra]

Hello @paul bryant

You have asked a very broad question and frankly there is no concrete answer, because it depends on how your teams respond to the tools and there might be changes required in the process after getting few feedbacks from the team. Thus, if it's a large scale rollout of the Atlassian stack then it can take easily upto 6 months for things to be stable across all teams in terms of permissions, workflows, automation , reporting etc. 

I have been in a similar situation at a client and here's how we did it. Basically, use confluence for managing requirements and use JIRA for managing the projects. Use a single project in JIRA. Use type hierarchy like Initiative -> Epic -> Story. Make sure your requirements in confluence are mapped to either Initiative (6 months worth of work) or Epics (around a month's worth of work) . This can be done by linking confluence pages to JIRA initiatives and epic as confluence and JIRA can be seamlessly integrated via Application Links.

Make sure in confluence that you have an proper content structure hierarchy which the teams adheres to, like -Parent Page (initiative in jira) -> child pages (epics in JIRA) 

Thus all major requirements and architecture/process flow diagrams can be developed in confluence but at the same time linked with JIRA tickets. Also, in confluence make use of "JIRA macro" filter to fetch statuses of JIRA issues within confluence so that the POs, BAs know within the confluence as to how much the teams have progressed in JIRA.

I hope this gives you somewhat of a start.

[paul bryant]

Hello @Tarun Sapra

Thank you for your quick response.

Ideally I wanted to manage the distillation of the lower requirements down to the STR level ( Statement of Technical  Requirement) in a set of sprints and then have a review process to then add these to the backlog for the implementation sprints. So far I have managed to get a work flow to work for the approval of requirements. but effectively if I keep it all in one project I need two in sprint loops (TODO, IN PROCESS, DONE) one for requirement work and the other for the actual development work. Here is the workflow 

Thanks

Paul

[Tarun Sapra]

Hello @paul bryant ,

Now, I clearly understand from your workflow what you are trying to implement. I have implemented something similar at my current place of work, thus I will suggest you not to go for 2 sprint loops but you are on the right track.

Basically, for the Refinement process (done by BAs/POs) created a Kanban board and once the issue moves to the right most column of the kanban board (done) then it should appear automatically on the scrum board backlog. For this you have to map your statuses in such a manner that first 3 should be on kanabn board and 3 to last status on the scrum board. It's important that you have Kanban board for POs so that you don't timebox their work. Because it's the Scrum team which is actually delivering the end value whereas the work/refinement for the POs should flow seamlessly instead of being time-boxed.

[paul bryant]

Hello @Tarun Sapra

Thank you for all your advice.

One last question if may, given what Im trying achieve, is the in-built features around requirements suitable or would I be better investing in a plugin to handle the requirement management such   Requirement Yogi?

If so which one's have you used for your projects?

I expect we could end up with at least 500 requirements across infrastructure and software .

Many Thanks

Paul

[Tarun Sapra]

Hello @paul bryant

I haven't used requirement yogi, so can't share much about it. But while implementing the requirements management process I generally use built-in confluence and jira capabilities along with 3 essential plugins for reporting purposes. As it's very important to have effective reporting dashboards for all levels of teams i.e. from C level management upto to Scrum teams. Each management level should have their own reporting dashboards giving them the info which is most crucial for them and hence incorporating transparency into the whole system.

• Better Excel
• Arsenale Dataplane
• Script Runner

If you are satisfied with the answer, please accept the answer so that others are helped as well.

[paul bryant]

Hello @Tarun Sapra

Thank very much for all of your advice.

Thanks paul