Best practices for organizing tickets from forms?

[Yancey Larochelle-Williams]

My team wants to start allowing stakeholders to submit requirements directly into our backlog. I have a couple of ways I could accomplish this, and I wanted to understand what everyone has tried to make a scenario like this work.

• Option 1: Use the new form feature to allow users to create stories (we already have fields for acceptance criteria and requirements, but this doesn't allow us to separate by source - can't hide a label on tickets created by the form like you could in JSD, for example)
• Option 2: Create a discovery project (really heavy process and is not transparent to engineering)
• Option 3: Create a new issue type (splits the difference between the two - with the advantages and weaknesses of both)

What would you recommend? Am I missing anything else that might be better?

[Stephen_Lugton]

Hi @Yancey Larochelle-Williams 

It does depend on what the team wants to get out of allowing stakeholders to submit requirements to your backlog.

A simple way of differentiating where a requirement came from would be to use the reporter field; set up an automation with an if / else condition.  Firstly, set up a group for team members, then check in the if whether the reporter is a member of that group, and if not add a label e.g. 'Raised-by-stakeholder'.  You would then just have to keep the group up to date.

You could also add in triage / refinement steps to the workflow that don't then appear on your board, e.g. additional statuses 'For triage', 'Accepted', 'To be Refined'

[Matteo Vecchiato]

Hi @Yancey Larochelle-Williams ,

interesting question. I think it is not possible to define if you are creating a work item thorugh a form or standard mode.

In my opinion, Option 2 and 3 create data stored in differents way, that is not a good solution.

But searching for a solution, I would suggest in order of preference:

1. Maintaing the same work type and introduce a custom field "source" as required field (and it works with form too)
2. Split in 2 different work types

I hope it helps