Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,456,968
Community Members
 
Community Events
176
Community Groups

Tracking stakeholders at the Feature-level

Hello,

I'm trying to figure out Jira Align functionality that could be used to track Stakeholders at the Feature-level. I've shared some context below - I'd love to hear how you've dealt with a similar problem or any suggestions. 

Background:

We have a shared services portfolio setup in Jira Align, with multiple Programs and multiple Teams under them. There are also other portfolios setup within the enterprise.

We'd like the ability to track key business stakeholders we're collaborating with at the Feature-level. These business stakeholders may or may not be Jira Align users themselves.

We'd like some minimal ability to view/report on Features based on the stakeholders involved. The reason we want to do this is more to manage communication and engagement given the shared services context - we don't need them to have access to Jira Align directly.

What we've tried:

We've tried enabling the "Requester" field on the Feature. It doesn't meet our needs because:

  1. It only allows the selection of one Requester per Feature (we need potentially many)
  2. The list of Requesters is shared across the entire enterprise - not limited to a portfolio (the shared nature isn't the problem but finding one person in a sea of many would be unusable since its a single monolithic list. We also don't want to end up replicating the company directory in here.)
  3. "Manage Requester" permissions are needed to add a Requester if one doesn't exist in the list (tradeoff between data quality and admin overhead if we open up this permission)

2 answers

1 accepted

3 votes
Answer accepted

@Sonal Hey! Have you explored the Customers option? If not, I would recommend this. You will face some of the drawbacks that you mentioned with the Requester option but may solve some of what you're looking for.

Similar to the Requester field:

  1. The list of customers is shared across the entire instance and cannot be limited by portfolio.
  2. This is also controlled by a permission toggle as to who can add customers.

Some benefits that might interest you:

  1. Like Requester, controlled by a toggle in the Details Panels Settings, which is by portfolio. Even though the options presented would be global, the display of the field is by portfolio.
  2. Can be added to features as well as epics.
  3. Ability to select more than one as shown in the screenshot.
  4. You can filter in the grids and backlog by this field, but you can only select one customer when filtering.
  5. You can also look at roadmaps by customer, again only a single customer, by selecting the Briefing option.

Aside from this option, I am out of ideas. I'm not aware of any options that will restrict the dropdown selection to be only for a specific portfolio.

Screen Shot 2022-12-07 at 2.05.37 PM.jpg

Thanks for the tip @Rae - I'm playing around with the Customer field in our test instance right now!

2 votes

Hi @Sonal ,

@Rae Gibbs is correct on native field functionality. Customer is a better solution than Requestor for all the reasons stated above.

There are two other options I can think of that are a bit non-standard.

  • The first one is to use a custom field - a multi-select drop down to be more specific.
    • The benefit is:
      • an admin with correct rights can add a list of known names to the drop down and people can select one or more.
      • You can run reports against that custom field and it is included in export files and/or rest api 2 calls.
      • You can even add names to the list via an api front end external to Align, which would solve for maintaining multiple lists.
    • The drawbacks are that:
      • It uses one of your 2 available custom multi-select drop down fields.
      • The field and the name list is specific to the object (feature) and a single portfolio.
        • You would need to duplicate the field and list for each portfolio and potentially the portfolio epic as well.
  • The second option is to maintain a table in Confluence or elsewhere via an api call that contains all of the features and the stakeholder names.
    • The feature ID and other info would be pulled from Align while the stakeholder names would be maintained in Confluence linked to the feature ID or in another datastore.

Regards,
Peter

VP, Business Agility, Praeciio

Thanks @Peter Jessen! I'm looking at custom fields too. My understanding is that custom fields are only available in Detail views - so I need to work out the tradeoffs with the flexibility they bring.

Thanks for the Confluence integration idea - I'll share it with my team.

Suggest an answer

Log in or Sign up to answer
TAGS

Atlassian Community Events