Advice on initial Jira configuration

Hi there,

 

I'm hunting around to find some advice on setting up Jira. I'm working for a newish company (a few year's old) - and getting some of the internal processes set-up - focusing on IT. I want to set some standards for defining projects, epics, etc. I was looking for some advice on how people tackle this.

 

One of the challenges we have is that we are doing three things at once:

* Building to specific customer requirements

* Building products (with a set of features)

* Building a platform (with a set of capabilities)

 

A product features use part of one or more platform capabilities; requirements will produce product features. At the moment, our development is led by customer requirements; in the longer term, we plan to move most customer requirements to configuration and focus on developing product features - and developing those features will add or extend the platform capabilities. I need to be able to report on all three - customer, products, and platform covering progress, current backlog etc.

 

To deliver this, we're working across multiple teams - business analysts, data scientists, and multiple development teams; along with the product team that prioritises the work. I'm moving the team towards Agile - starting with monthly sprints (including the planning review cycle). My team doesn't own customer projects - these are owned by another team, although much of the work currently drops in to the development teams. Most features/capabilities will stretch across multiple teams.

 

The organisation uses Jira to manage all sorts of stuff (some HR, some IT). I can shape their use a bit, but I can't dictate it. In the short term, we're using Jira Cloud; we may migrate to our hosted version in the future.

 

In the midst of all of this, I need to set-up a basic Jira process to manage the work for the development teams, to report across all three levels (requirements, features, and capabilities). I need to make a decision around the project structure (ranging from one big project to a project for each customer, product, and platform).

 

This is a long question, with a lot of background. While an comprehensive answer would be much appreciated, it's unrealistic. So I'm mostly looking for somewhere I can go and get advice on best practice and start designing the system.

 

Thanks,

Geoff.

1 answer

1 accepted

Hi Geoff,

 

I have exactly the same setup and have worked through a number of different variants over the last 4 years.  You won't find many references that will give you answers, it's basically trial and error.

Here is the high-level answer I provided for another post on a similar topic.  I'm happy to talk parts through in more detail if you want (available over Skype) as I have felt the pain and think the solution we have is the simplest and most usable and I like to share any knowledge across the community to help where I can

 

Here it is:

 

Your right.  there are probably a number of ways you could solve this.  What you describe isn't normally the biggest problem people have an issue with.  It's normally'How do we re-use Stories for our product with other teams.

Anyway, let me give you an example of how we have set ours up to see if that helps you.  I think it matches with the way you already have yours working.

We have:

  • A product which is built up of multiple solutions and developed by multiple product teams. 
  • A number of customer-facing teams who deliver the product (take the product, customize it, maybe build some bespoke features) to our clients.

We have kept the structure as simple as possible.  In order to do this we haven't created any new issue types\hierarchies in Jira.  This enables us to keep the system performant but also means that as we hire new people we don't need to train them too much on a customized approach.

 

Essentially we have pretty much what you described (and believe me when I tell you I have tried many, many different approaches).  The structure is this

  • Version\s (one or more to track a release\s for a project or product team)
  • Epic\s (to track features we are going to build.  Obviously these can be quite large in size)
  • Stories (These are our business value.  Including acceptance criteria and meeting INVEST principles)
  • Tasks (More technical in nature.  These are a maximum of 1 or 2 days in size.  These are linked to Stories)
  • Sub-tasks (Under Tasks to plan exactly what needs to be done in more detail)

Our Tasks are used by the teams and are created during refinement.  It enables our Stories to stay intact and keep the business value while the tasks can be split down by the teams any way they like, giving them full control to work as they wish.  The team might split by screen section, data, etc, etc.  This also adds another benefit.  As we don't split the stories down themselves we retain all the info in them and then those stories can be re-used across other customer projects.  The stories form our product documentation and our Intellectual Property.

Yes, it takes some additional effort to link Tasks to Stories but not a massive amount.  You can do this in Excel to speed it up and just import them.  Jira will merge any changes too.  It also keeps Jira in a standard format.

Visibilty wise we track the versions through the version report, but we also use Arsenale DataPlan reports plugin to show a nice graphical percentage complete for one or more versions.  This is a bar chart.

Again, we use Dataplane report to show progress per Epic (Feature) in a nice bar chart.

Stories don't move through our workflow really.  The teams move the Tasks through our workflow and then as a final step (once all related Tasks for a Story are complete) the team simple review the Story together and close it.  Stories just move from To Do -> Done.

Hope this helps.

 

If you have any other questions let me know.

 

Mike Kinloch

Head of Development

Intelligent Environments

HI Mike,

 

Thank you for your answer - it's extremely helpful. Your approach similar to what I was thinking, but more refined (no doubt from your experience!)

 

Given that, the big question I still have is around the project structure to support the issue/task structure you've described. I'm leaning towards having a big development project, using components to map to capabilities, the using the epic/story structure you describe to manage functionality.

 

If you're available for a chat, that would be much appreciated. I'm g.goodhew on Skype - drop me a message and we can co-ordinate (I'm in the UK). 

Ok.  I dropped u a message earlier.  You should have my details now.

 

Mike.

Suggest an answer

Log in or Join to answer
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

2,789 views 11 18
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot