Project setup question

[Josh]

Hi - I'm currently looking to setup a project that supports a product that has two main tracking elements (new features, new client deliveries).  Deliveries <> releases!  We can use Epics for one but not both since the work underneath may be part of both a delivery and a feature.  Using a label or other custom field is possible, but doesn't give us the amount of metadata an epic provides.  Within that project setup we would need multiple boards for the typically teams in the delivery life cycle.   

How could I manage my Features and Deliveries separately in the same project?

What kind of project should I set up to get the most flexibility it create custom boards and workflows?

[Trudy Claspill · Accepted solution]

Hello @Josh 

Welcome to the community.

I recommend setting up Company Managed Software projects to get the most flexibility for creating custom boards and workflows.

When you say work can be part of both a Delivery and a Feature, is it truly one work item used in both, or is it work that is done twice - once for Delivery and once for Feature?

[Josh]

Hi @Trudy Claspill  thanks for your reply!!  We will have Delivery items, and Feature items that are mostly separate.  But some times the delivery is dependent on an item or two that is part of a Feature.  So one item, but satisfies the progress of both the feature and delivery it is tied to.

[Trudy Claspill]

Off the top of my head, without a ton of deep thought, this is my suggestion. 

Track both your Features and your Deliveries using the Epic issue type. Use a label, or the Component field, or a custom field, or simply the Epic Name to designate that the Epic is either a Feature or a Delivery. Or use one project for Features and another project for Deliveries.

For the child items (of Features) on which a Delivery becomes dependent, either

1. create an independent child item in the Delivery, and link it to the child item in the Feature using the generic issue linking functionality. I'm not sure if depends-on/has-dependents is a built in relationship for generic linking, but if it is not you can add it.

2. create the above link directly between the Delivery epic and the child item of the Feature.

Note that there is no built in functionality in Jira based on the generic issue linking. If you needed actions to happen automatically based on changes in issues involved in such a dependency link, you would have to create customizations for those actions.

Would the workflow for Delivery items be the same as for the Feature items? If not then I would recommend tracking them in separate projects. Otherwise setting up custom issue types to let you use different workflows in one project would make it more complicated.

Are the teams going to both use Kanban or both use Scrum, or one use Kanban and the other Scrum? That might influence if it is easier to track the data in separate projects.

There is a lot of flexibility to create boards based on saved filters, so you could create boards for each project separately, boards that combine the data of both projects, or if all work is tracked in one project then boards for a subset of the data (one for Delivery and one for Features).

[Josh]

Thanks for the info @Trudy Claspill , is there a way to easily bulk update stories/tasks to "relate" to an epic?

[Trudy Claspill]

Linked Issue changes are not available in the Bulk Change feature, unfortunately.

If you can come up with a JQL statement that identifies a batch of issues you want to link to a given epic, you could make a manually triggered Automation rule to do it.

[Sachin Dhamale]

@Josh ,

If you have jira cloud Premium then you can you roadmap functionality there you can have multiple level above the Epic.

You can use Epic as releases and create new issue type called Deliveries and link Deliveries to releases using specific link type and in the road map you can see the hierarchy. see bellow