Advice on initial Jira configuration

[Geoff Goodhew]

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.

[mike Kinloch · Accepted solution]

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

[Geoff Goodhew]

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). 

[mike Kinloch]

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

Mike.