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

Next challenges

Recent achievements

  • Global
  • Personal

Recognition

  • Give kudos
  • Received
  • Given

Leaderboard

  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Please help me with a proper way to use jira

Hello,

First of all, sorry, if this comes off as a stupid question. But i'm kinda lost.

So we're a pretty typical software development + implementation project company.

Most of our work items, or stories (i'm sorry but i'm not fully up to the whole epic-story-task-subtask hierarchy, how should that be used?) involves two people - a consultant which is aware of customer requirements, does the functional design and then the testing, and a developer, which does the technical design + coding.

Up till now, we had a pretty complex workflow involving many status changes from billable yes/no, billing accepted yes/no, open, in progress, in development, testing, reopened, dev done, ready to deploy, deployed, billed, closed. Something like that.

And this worked really fine - when a consultant would finish his phase of task, he'd just press a button, enter time spent, enter a comment, change the assignee to a dev, and so on.

Was easy to use and totally understandable.

Then came the planning.

So we wanted to know the remaining workload of everyone. The velocity per person, if I can say that. Compare, measure and plan.

And shit hit the fan.

Since we only have original estimate/remaining estimate once per task, this doesn't work anymore. This gets counted for whoever is the Assignee of the ask. 

Fair enough, we thought. Let's use sub-tasks for the development. 

And this is where it got terribly un-userfriendly.

Because the statuses can't be linked, whenever a consultant would finish his work, he would have to change the status of dev sub-task to indicate that it's ready to be done. When a dev would finish, he'd have to complete his sub-task, and change status on the main task, to indicate that it can be tested. If there's a problem, and the dev needs to repeat it, the cycle repeats. Not to mention the scattered comments between task and sub-task.

And while this does in fact help us to know the workload and personal input to everything, everyone hates it. I hate it too.

So how does everyone do it? What is the proper way, which is both user friendly and helps to plan and analyse?

 

4 answers

Hi @Algirdas Kepežinskas

It sounds like you have quite a complex method of using Jira - I'm a big fan of simplification, perhaps I can assist a little through some suggestions:

Epic > Story > Sub-task:

  • This is a base agile concept around breakdown of work. If you base it off Story, which is a small, independent piece of value to be delivered, a Sub-task is a task to complete the story, whilst an Epic is a large user story or collection of stories with a similar intent, value or theme.
  • Depending how big each of your client requests are - I'd consider expanding your hierarchical breakdown to consider Epics - i.e an Epic might be the request, the Stories / Tasks work to complete, and Sub-tasks reserved for further breakdown of specific deliverables.
  • You might want to also consider splitting into different issue types to make the split more visual - i.e Tasks for the consultant, Stories for the developer.

Assignee vs Reporter:

  • There are two standard user pickers on an issue - Assignee (whose working on it) and Reporter (who is responsible for it).
  • If the Assignee changes too much - you could also utilise Reporter to set a consultant or developer who is responsible overall - thus tracking a consistent user against estimates.
  • If necessary, you can add additional user pickers - see more on custom fields here.

Workflows / Issue Types:

  • By splitting into Epics, Tasks and Stories - you can also enhance your workflows. This might simplify your flow a little allowing you to have less statuses per issue type. 
  • Alternatively you could still have different workflows between Story and Sub-tasks - you could take this further by adding extra Sub-task issue types, such as Tech Task and Business Task and having workflows for each.
  • See more on workflows here; and more on issue type creation here

Automation:

  • You can automate to an extent in Jira using workflows - check out post-functions in this article here for some ideas. This can help with auto-assignment of issues and such.
  • Alternatively you can use a scripting app or an automation app - like Automation for Jira - to automatically change statuses or assignees depending on your individual scenarios. We use apps like this to reduce the manual work involved.

General:

  • Don't forget to use the base tools - Boards for example you don't mention here but these are very powerful. Here a Consultant and Developer could see the tasks to complete, move multiple issues through statuses and see a clear picture of what is needed next.
  • If you need to link issues together, consider linked issues also to show issue 1 blocks / is needed by issue 2. It can be another way to link across rather than just via the hierarchy.

These are all just ideas - it's hard to offer specifics without knowing more about your scenario but hopefully this gives ideas based on my previous experience in these spaces.

Ste

0 votes
Jack Community Leader Jan 21, 2020

Hi @Algirdas Kepežinskas , it is difficult to advise you based upon your post TBH. I would really need to better understand your workflow and process to feel comfortable providing a reasonable opinion. On the surface it feels like maybe your workflow is too complex and maybe using Issuetypes to break your workflow into more manageable pieces of work would be good. Example, maybe planning, documentation, development, etc. Just a guess though. That aside, regarding the issue of the user having to update sub-task and parent you could consider automation.

Hey.
Maybe solve each individual part in individual Task help you. When you close a task, you should have two transitions: 1) ready, close 2) ready, pass to the next one. And with #2, you create a linked task - it can be done either manually (not interesting) or automatically, for example with this plugin (we use it).

In this case, the task of each participant will be separate, you will be able to track it, and participants will minimize manual work.

Thanks everyone for the answers. Since I'm getting somewhat generic answers, I assume I wasn't specific enough with my question.

I'm ready to detail the use case as much as needed, provided anyone wants to help me with the most practical/most often used way of solving it.

Here's my next line of thoughts:

I assume, that we do need to have separate tasks/sub-tasks for consultants and developers, since it's a requirement for planning and measurement to have estimates, remaining estimates and time spent per person. 

Since I don't see how to get around without this assumption, this leaves me with one very specific question:

What is the most efficient, easy, and user friendly way to link those tasks/sub-tasks. And by link, I mean, to be able to setup a workflow which involves changing statuses between the linked tasks/sub-tasks, when one of them changes status. So that, if, for example, development task/sub-task is Done, the testing task/sub-task changes to status Ready for Testing. If Ready-for-Testing becomes Reopened, development task also changes to Reopened.

We're ready to buy/use a plugin for that, but since we have many different work processes in the company (projects, product development, support), this has to be quite flexible to setup and change. 

a) I think this is not possible with stock Jira. Am I correct?

b) What extension would be most ready to do this?

c) How do other companies use Jira, because this use-case seems pretty standard for any development company?

Thanks!

Suggest an answer

Log in or Sign up to answer
TAGS

Community Events

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

Find an event

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

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you