Manage same input data for several deliverables without creating duplicates

Garn_lgavks

Hi Community,

I'm using Jira software Datacenter instance version 9.4.8.

I need some ideas or advice regarding how I manage my data in my Jira Project.

 

I'm creating a new project with the goal to list deliverables, and describe for each deliverable the input data I need to create it. I want to know before creating my deliverable if I have everything in my hand and when I should ask for the input data regarding the delay to receive them.

 

Basically, my first idea was to create :

1 task = 1 deliverable

1 subtask = 1 input 

So, for a deliverable which needs 5 inputs, I have this ordered by what I should ask for first:

When my input is requested, I will change my status to "In progress".

When my input is ready, I will change my status to "done".

 

 

My concern is:

The same input can be requested in different deliverables. With my first idea, it means I will have subtasks with the same name created as duplicates. I was thinking about using duplicate link to transfer the data when input is provided. 

I would prefer to not have duplicated subtasks to reduce the volumetry of tickets in my project and make sure we are not loosing information with all the duplicates.

 

Any idea how to reorganize my deliverables and inputs?

Should I define my input as a task, and use a new link to define "belongs to" a deliverable?

 

Don't hesitate if you see other options or need more information.

Thank you!

David Nickell

I don't follow your need completely but that may be due to a lack of caffeine on my part ;-).  

The use of Components may be the magic you are looking for. 

• Assuming your organization produces software applications, your application can be broken into Componets.   
• You can use Confluence to hold requirements, test cases, release notes, etc.
• Jira can be used to track the work needed to deliver a new version / enhancements.

So when you speak of input coming from multiple sources, make Confluence your "source of truth".  In fact it can be useful to restrict who can update your confluence pages.  That way there is no confusion as to what the intended results of your work were supposed to be.

I hope this helps.  I ran into the "multiple versions" of requirements at one employer... in fact it was so bad they had the same information in 7 seven places as I recall.  (Does the Confluence Requirement match the document the client provided?  Does the test case reflect the right information?  What about user training? Add Jira tickets and the actual software itself.... I guess I rattled off six)