Organizing work into workstreams within a particular intiiative.

[Bhuvaneswari Vasudevan]

I'm looking of best approach to handle our scenario as we are starting our journey to deliver multiple initiatives as part of our roadmap for next 12-18 months.

Our product team uses idea in JPD to  represent the initiatives under our roadmap and the features under each of them as epics. Once the work is committed, we create an initiative in Jira and epics underneath it.  Most of the DEV work related to configuration is being handled as Task work item.

Challenge:

Within each initiative we have workstreams and each workstream has set of internal (Eg Internal beta) and external (user facing) milestones. Each workstream might have one or more epics and may have multiple releases like  Alpha, Beta.

1)We are unable to figure out the best way to represent workstreams apart from the suggestion to use labels. Is there a better way to group work within Jira as workstreams?

2) What is the best way to represent milestones for each of the workstream and also to differentiate between the internal and external releases?

3) We are hoping to use the release - Deployment ticket to differentiate between different releases. Do you see any challenges in associating milestones with the deployment cards?

4) We would like to setup a view in plan that will have below hierarchy for each initiative:

Level 1: Initiative   (Project)  ==> This might run for 12-18 months

Level 2: Workstreams  ==> This might run for 3-6 months

Milestones to be setup for each workstream

Level 3: Epics for each workstream that will group the work required to deliver the outcome

Level 4: Work items

5) How do we best capture the baseline date for the workstreams and initiative level and track the dates when there are change request for start and end dates?

6) Our development team has been using Task for any work that is not related to product feature (Eg setting up infrastructure components, API integration etc). THis has led to losing visibility on the work accomplished. How best to handle the Developer only work related to configuration, infrastructure setup etc.

Appreciate any reference to use cases/implementations that has used such scenario.

[Joshua Brock]

@Bhuvaneswari Vasudevan 

Greetings and hope all is well.

Wanted to pass along some thoughts from one of our seasoned Sales associates, with many years in the Atlassian ecosphere on your questions.

To be transparent, I work for Agile Hive, which is a Scaled Agile Framework (SAFe®) plugin for Jira that enables organizations to implement SAFe practices within Jira. May not be totally applicable to your situation, but just some notes.

If you'd like additional information or to follow-up should you choose this route, please feel free to reach out to me here...thanks!


Joshua
Content & Technical Writer
Agile Hive (A product of Seibert Group, GmbH)




1)We are unable to figure out the best way to represent workstreams apart from the suggestion to use labels. Is there a better way to group work within Jira as workstreams?
-- If JDP created the initiatives and epics, then it might be hard for you to take a different approach. That said, since you are using initiatives that Agile Hive uses Portfolio Epic. You are using Epic, that would be replaced by Capability (can also be seen as workstream) in the Large Solution layer. The ART layer would be GROUP of features that are tied to each workstream from the Large Solution layer.

2) What is the best way to represent milestones for each of the workstream and also to differentiate between the internal and external releases?
-- Since each Layer has the milestone issueType, you would create a NEW milestone and probably use related to properties to tie multiple workstream to it.

3) We are hoping to use the release - Deployment ticket to differentiate between different releases. Do you see any challenges in associating milestones with the deployment cards?
-- Because Agile Hive milestone is an issueType, there should be no challenges. It is the Story issueType in JIRA that should be tied to a release if you are using Gitlab or other code repository.

4) We would like to setup a view in plan that will have below hierarchy for each initiative:
Level 1: Initiative   (Project)  ==> This might run for 12-18 months
Level 2: Workstreams  ==> This might run for 3-6 months
Milestones to be setup for each workstream
Level 3: Epics for each workstream that will group the work required to deliver the outcome
Level 4: Work items
-- Our LARGE SOLUTIONS report is soon to be released and the report for Portfolio is still being developed, we would suggest using Confluence to provide that information.

5) How do we best capture the baseline date for the workstreams and initiative level and track the dates when there are change request for start and end dates?
-- Since there is NO PERFECT way since agile and new stories can suddenly appear that changes the dates. We recommend using AWESOME CUSTOM FIELDS from Seibert (our parent company) that an automation rule can be used to hide custom field so when the start date is set, it stores it into an invisible field that no one should be allow to change. As for the End date, export the data into an ad-hoc reporting tool to find stories with a date that is greater than the wish date of completion.

6) Our development team has been using Task for any work that is not related to product feature (Eg setting up infrastructure components, API integration etc). THis has led to losing visibility on the work accomplished. How best to handle the Developer only work related to configuration, infrastructure setup etc.
-- ALL work needs to be a Story and sized. We recommend a DROP DOWN for that to separate Development from Configuration work. And with this custom dropdown, they have the option to add future tagging with no issues.