How do you collect your requirements for setting up Jira Projects?

[Carol Low]

Hi Jira Admins,

Pleased to meet you all! I'm Carol, a product manager working on Jira's project configuration. 

Keen to understand what are your best practises for collecting requirements for setting up or configuring Jira projects. Do you have a template for the teams to fill out? What have you found to be the most important questions to ask?

Bonus question: Have you found Team managed projects (previously Next Gen) useful for letting teams do their own configuration?

[Jonas Börnicke]

Hey @Carol Low 

We set up a "template" project that is configured in a way that is needed in 95% of the projects. When creating a new project, we use this template's configuration (workflows, screens, issues types etc) and then clone the relevant template issues into the new project (having the option to just copy a project would be awesome, btw). Our projects are standardized as far as possible to make working on multiple projects as frictionless as possible, so we do not ask the users for input when creating projects but rather when designing the whole Jira system.

We are not using Team managed projects because all users would have to spend quite a bit of time understanding how to set up Jira and because we want that standardization.

Cheers

Jonas

[Carol Low]

Hey @Jonas Börnicke

Thanks for sharing! Out of curiosity, what's the reason for cloning rather than just sharing the config/using the "Share settings with an existing project" option? (I can imagine a few, but keen to hear your point of view)

Cheers,

Carol

[Jonas Börnicke]

Hey @Carol Low 

We do use "share settings with an existing project", but that does only cover a few settings. Issue layouts, people, automation, boards/board settings and many more are not covered by this. So just having a way to make a perfect copy of my existing template project with a new project key would make life sooooo much easier. This would allow all our users to set up new projects. Right now we need a quite extensive guide to explain all the necessary steps to create new projects properly. In a perfect world the copy process would allow choosing all the aspects that I want to copy, maybe even choosing the issues that I need in that specific project (different functionalities and their standard issues are collected in Epics for us). Deep Clone does quite a nice job for closing issues, a similar (native) functionality for projects would be great to have (but I am not a dreamer and there are more pressing improvements in Jira that will get priority😉).

In the end it usually comes down to me setting up new projects as our users do not feel comfortable with all the things you have to adjust. I am better off spending 15-20 minutes creating a new project rather than checking all the settings others miss when doing it.

[Curt Holley]

Being able to clone a project right down to the automation rules as @Jonas Börnicke has suggested would be cool. Not sure I would want the People section copied over though, as surely each project has quite a distinct line-up of people.

[Jonas Börnicke]

Hey @Curt Holley 

For us, projects really do not have distinct line-ups. Our small agency grants general access to all projects to our whole staff. We use "People" with user groups to assign different security levels, for example allowing us to discuss billing details in comments that only management can see.

So really having the option to choose which sections/settings to copy would be the necessary way to go. Without manual configuration of what to copy and what not, the feature would not be all that helpful for most people.

[Sergei Gridnevskii]

Usually I sit together with project manager, he tells me what he wants and I tell him if it is possible or not. This relates to completely new projects. For existing we just copy original project and set up new people in it. 

Also there is always a choice between complexity of a workflow and "state" fields. I have a little questionair for managers concerning workflow steps and custom fields. For example,

1. How much time do you think an issue will be in this state? 

If it is less than 1 hour, it is a good candidate to be removed from a workflow

2. Do you plan to search issues using this field? Or is it just for "documentation"?

If it is just for documentation, it is a good idea to add this info to Description instead of adding a new custom field.

Anyway we continue planning even after project is put to work and changes are made from time to time.

Concerning next-gen... I personally use it for Jira configuration issues, but guys tend to use classic projects.

[Angela Stephens]

I also always ask about reporting requirements as well.  If they want to report on any data, it's important to consider if it should be a custom field, how it should be formatted, required field versus optional, etc.

[Carol Low]

Hi @Sergei Gridnevskii

Thanks for sharing! I really like your questions to identify candidates for reducing complexity.

[lora_grancharova]

Thanks for sharing, @Sergei Gridnevskii I like your questions too. That`s very important and  also great topic of discussion.

[Vaishali Patil]

We have a template project for development. We have created a webpage when the requester has to fill in information like what security scheme they would need. Options for some of the dropdowns which have a context etc.

Based on the information that is provided, I create the project, add people in roles etc. Some of the things are done through the API and some are done manually. Once the project is created, an email is sent by the webpage to all the necessary folks.

[Rich Wolverton]

Since all project manager and all projects are not alike, we work with individual teams to set up projects. Our previous experience moved us to creating all projects as Scrum projects and then modifying them to the initial project configurations agreed upon in the planning stages. This is because, while many projects we not comfortable starting off with Sprints, once the got comfortable with Jira, many wanted to add Sprints.  

We are in the final stages of moving to Atlassian Cloud and expect to revisit project standardization given all the new options available in the Cloud, including Team Managed Projects.

[Taranjeet Singh]

That's a very important and great topic of discussion. It is really a good opportunity for me to learn from the experiences of all the users and different approaches followed by the users who shared them in this post.

Involving the right people, and asking the right questions to gather requirements for setting up a new project are very important aspects.

It is also very important for a Jira Admin to guide these new project users, during the requirements gathering process, on what configuration elements are available out-of-the-box in Jira that can be used to suit their needs without doing too much customization in order to achieve the goal of maintaining standard project configs and an easily maintainable Jira instance. So, the questions should also be designed based on that.

[Lorenzo Phillips]

As an Atlassian partner, we work with a lot of clients every year. So what we do as a minimum is setup an Atlassian Support project (if they don't have Jira Service Management) or we setup a company-managed Jira project.

While a JSM project easier to put textual content together so the users know which option to select, non-JSM projects or regular Jira projects need additional guidance.

For typical Jira projects, we create an associated Confluence space that contains basic guidelines that state, if you need modifications to an existing project, open a Task. If it is a new project that can use one of the template projects we've setup for them, they also open a Task and then we track modifications via Subtasks. If it is a new project and it is significantly different from the existing templates, then we have them open an Epic. Then we meet with the stakeholder(s) and we open up Stories on the Epic to track the work.

We use the tools as much as possible as consultants because it gives us an easy way to show our work, progress of work, how many tickets we've closed, etc. This works MUCH better than trying to do status reports. It also displays the power of the tools when used correctly. It also leaves critical information about why things are setup and/or work the way that they do as our clients can search past tickets for key decisions, who the decision makers were internally, etc.---long after we have left the client site. ;)

For those that are doing migrations to the cloud, I must take a minute for a shameless plug. We have noticed over the past (3) years that clients just want to get to the cloud and thus, our efforts to clean up before migrating have failed:

• Too hard to get the time of project owners to discuss everything they own.
• Too hard to get multiple stakeholders to agree on things if they're sharing schemes.

On and on, but the point is we've had 100% success by migrating them first and cleaning up afterwards.

Now, the to plug--I created (2) cloud admin apps called Instance Auditor (Jira) and Instance Auditor (Confluence). My apps quickly count up all the projects, workflows, issue types, schemes, etc. and reports can be exported and provided to the stakeholders so a review can be done quickly and easily. Then we use my apps to delete in bulk easily and quickly (where the Atlassian API allows us to do so).

Anyway, this is a brief summary of the processes we use to get clients what they need, quickly and easily and it has worked for us for 10+ years. :)

[Carol Low]

Hi @Lorenzo Phillips 

So good to see best practises from a partner who does this for many clients! Do you find that your template projects cover most of the use cases? How many different templates would you say is regularly used?

Cheers,
Carol

[Lorenzo Phillips]

@Carol Low 

Once upon a time before all of the recent changes to the products, we would typically setup 3-5 project templates but it really depended on the client. For example, we'd setup a template for:

• Business teams
• Dev teams
• IT teams
• Internal/External teams (where the client allowed external access to the tools)

But the key is to setup templates based on the clients internal structure as there were times we could just setup a single project template as that's all the clients needed.

But the client had to be dedicated to their processes across the org in order for this to work properly as everyone always thinks they have a special case and need their own customizations. Lol. In the absence of processes, we do attempt to help clients establish them so they can be successful and reduce their maintenance overheard once the engagement was over.

If org-level process adoption was not present and the client had no interest in setting them up, we still setup templates that targeted the clients most likely use cases (goal was 90% of the user cases) and allowed their internal Atlassian team to customize them as needed.

If a client didn't have a strong Atlassian team internally, we would allow the Project Admins to use the team-based (old next-gen) projects to reduce customization bottlenecks, but definitely implemented cleanup policies as the duplication of statuses, workflows, issue types, etc. grows quickly under this model and can quickly impact performance.

I should note that after attending Team '21 this year, I did revamp our offerings as I believe the integration with other tools will help clients to adopt standards so they get the best results from using a stack of Atlassian tools. For example, with Advanced Roadmaps, we alter the default hierarchy from Epic, Story, etc. to Theme, Initiative, Epic, Story as the Advanced Roadmap tool works best with this structure.

[Josh Costella]

UPDATE 5/21/21: We decided to take it a step further and replace our 13 different request types from 3 request groups into a singular request type thanks to Proforma! With the help of all the dynamic field capabilities, we are able to have a singular form for our customers that guides them through providing us with higher quality and more targeted information. This is already leading to less back and forth communication with our users, less meetings to discuss requirements, and quicker turnaround times! 

We recently built out a Proforma form to dynamically capture the high-level requirements of the request. 

As the users continue to update the form, additional requirements are prompted for and captured. 

As far as Team Managed, we have not given anyone the ability to create or request them. We have not had a request come through yet that could handle the limited features available in it.

[Carol Low]

Hi @Josh Costella

Thanks for sharing! Indeed Proforma forms are a great way to collect the requirements. 

If there were 1 or 2 features that if available would make Team managed projects an option, what would you say they are?

Cheers,

Carol

[Josh Costella]

I highlighted what I would like to see Team Managed projects have for me to start using them. 

[Vincent]

@Carol Low Any consensus on forms which might be good for spinning up a multi-team project?

[Sergei Gridnevskii]

For me it is pretty easy. I meet with the stakeholder, choose Projects in top level menu and ask him to select one of atlassian templates. We create the temporary projects together, I assign stakeholder as admin to this project and he plays with it for a week or so. Then he comes to me saying Lets do it like this but remove unneeded things. And lists them. 

After that I create a working project from scratch paying attention to security policies, custom fields, workflow step names and so on to make it like others in our organization.

Why we do not use Atlassian templates for active projects?

1. They are too complex in terms of workflows. Dozens of steps. I prefer minimal workflows where each step is a process, not a state (maybe except for Open and Done). E.g. Preparing Requirements is much better than 1. Waiting for preparing. 2. In Preparing 3. Requirements ready. Step is a verb, not a noun.

2. Atlassian templates use custom fields without care. E.g. I created a temporary project from template and it added Severity field. But I already had one in other projects. Consequently some of my automation rules stopped working. If I were an atlassian engineer I would use contexts if I find that the field with this name already exists.

3. It may be hard to remove a feature from a project if we do not need it.

But anyway as I said templates are extremely useful in terms to show to stakeholders what Jira can and make them understand what they want. I recommend using them when collecting requirements, at least as a starting point.