nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Checklist / tasklist for Jira Agile OnDemand?

Jon Logan

Hi,

We are in a real bind. We are using Jira OnDemand and Jira Agile. We just created a rigid new workflow that has our engineers & product managers & designers pass a given story through a linear workflow of Open->In Progress->Resolved->Needs Verification->Closed.

(We built this workflow ourselves and want to prevent people from leapfrogging from early steps like 'Open' all the way to 'Closed'. It is a good workflow for us!).

This all works great EXCEPT when we try to add subtasks under a parent story, bug, or task.

We were currently planning on using subtasks simply to track 'busy work'. Imagine this setup with the parent story:

Story: 'User gets a notification email after they signup'

With these subtasks:

'Design email template' (tracked by the designer)

'Write email content' (tracked by marketing etc)

'Build SMTP integration' (tracked by engineer)

And so on...

Our thinking was that tracking subtasks would simply serve as a 'task list' for our implementers to manage.

However, the progress of subtasks is much too tightly tied to the progress of parent issues, as far as Jira believes.

Jira seems to have a preconceived idea of how parent issues should behave relative to subtasks. I.e., by default, it thinks that if all subtasks are CLOSED, then the parent should be closable too. But we do not want this.

We still want the parent issue (Story, Bug, Task) to pass through the above proscribed steps (Open, In Progress, Resolved, Needs Verification, Closed). This is an essential part of our workflow that needs to remain enforced.

We understand that we can add a bunch of conditional states that might allow us to progress a story forward given our new workflow. However, the setup for this is mind-numbingly complex, and after a few hours, still does not achieve the simplicity we need.

So, all we really want is a lightweight 'task tracker' at the story/bug/task level, which does NOT require creation of subtasks.

For example, in the above example, our implementers would just create a shared checklist of items within a story itself:

For the parent story 'User gets email notification after signup'

Would have this simple to-do checklist:

'Design email template' (tracked by the designer)

'Write email content' (tracked by marketing etc)

'Build SMTP integration' (tracked by engineer)

Then the people can check these items off as they go.

All we need is a very lightweight 'to do task list' embedded within the story itself. Basically, WE WANT TO DO THIS THE WAY PIVOTAL TRACKER DOES IT! Pivotal has a very nice, lightweight checklist within a story.

Can you help us achieve this please?

p.s. we are on Jira OnDemand and cannot install the 'checklist' add-on that is available in the main marketplace. We believe that plugin (which looks perfect otherwise!) is only available for the app, not the hosted version.

Accepted answers

All comments

Nic Brough -Adaptavist-

>by default, it thinks that if all subtasks are CLOSED, then the parent should be closable too

You can easily remove the conditions that cause that behaviour. It's not actually what you describe though, it's actually "stop people doing these (close type) transitions if there are open subtasks", which is a slightly different logic. In fact, if you've been editing the workflow, you probably had to put that in deliberately.

I'd fix that first, then I'd have a go at the subtasks. Create a new workflow for them that just has "open" and "closed". That makes them behave very much like a checklist

I tend to find this works a lot better than checklists because you can see at a glance who dealt with a checkbox without having to plough through the history (last time I used pivotal tracker, the organisation was moving to Jira because the checklist functionality simply wasn't good enough, along with a number of other flaws), and you retain the flexibility to be more powerful as they're still issues in their own right.

Jon Logan

Nic, thanks for your quick and helfpul response. I'm still not convinced that true subtasks are warranted for us -- they are simply too 'heavy' to manage in our preferred workflow. Please see the two attached screenshots that hopefully convey some more info.

One issue has to do with the 'close conditions' that I still cannot figure out how to change. But the other larger issue is just how 'heavy' subtasks are compared to a simple lightweight checklist.

Here is the first issue: Jira wants to close the parent when the subtasks are closed, but that breaks our workflow.

Here is our bigger issue: Stories with subtasks are a much bigger pain to manage in workflow mode. We simply want the STORY to follow the workflow, and the subtasks to be OUTSIDE of the workflow.

Your help, and everyone else's, is invaluable! Thanks!

Nic Brough -Adaptavist-

Ok, so you're using the Agile functionality in a way that's quite removed from the way Agile is generally expected to work. The most obvious answer is that as you're not really being Agile, stop using the tools - subtasks prompting the parent to close doesn't happen when you work in "normal" Jira.

So, on the popup box, I completely understand the requirement to turn it off, but you can't do it (unless you're willing to hack a bit of code). Follow and vote on https://jira.atlassian.com/browse/GHS-8770

I'm really not sure you can get to what you need using on-demand. As you say, sub-tasks are too "heavy", you can't install the checklists. Sub-tasks outside Agile could probably be made to work for you, with a little TLC, but moving to plain Jira would lose you the boards etc. I think you might want to look at getting a different hosting company so you can use the checklist plugin or hack the popup out of agile.

Nic Brough -Adaptavist-

>Unfortunately, telling us to move to a different tools platform doesn't help us

> Does anyone happen to know if Atlassian would be able to give us checklist functionality

To deal with those two together... No, you won't get the checklist.

But I don't think I was clear about suggesting a move to another tools platform. There are other people hosting Jira + Agile + Whatever out there (including the people I work for). Many of them would be happy to take your current OnDemand data, import it into the same version on their systems AND let you install pre-agreed plugins such as the checklist. I wasn't suggesting different tools (I suspect you'd lose too much stuff that does work well for you if you left Jira), just running Jira differently.

Also, I wasn't saying you aren't "agile enough", just that some of what you are doing is quite a long way away from standard Agile and not well supported by the Agile tool. (If you do that bit outside Agile, in plain vanilla Jira, it won't hassle you!)

Jon Logan

Nic, again, I appreciate your response. Unfortunately, telling us to move to a different tools platform doesn't help us. We are a pretty old-school org here and just getting us up on the some of the basics of Jira Agile has been an enormous (but valiant & successful) effort.

On the subject of 'are we agile enough', my understanding, and that of many others here in the SF agile community, is that a development org should only be as agile as feels appropriate. This is why we like Jira, for its immense configurability.

I've worked in Pivotal shops before, where the notion of 'agile' is much more rigid than Jira out-of-the-box. But Pivotal doesn't even have any concept of child-subtasks, and instead implements a basic to-do list at the parent level. This is really all we need, just the ability to check off a list of busy work within a given story.

Does anyone happen to know if Atlassian would be able to give us checklist functionality (via a manual intervention) even though the add-on is not available on the OnDemand marketplace?

Barring that, we are probably gonna do away with subtasks entirely and ask our team to just track their work at the Story level (like Pivotal).

Jon Logan

Thanks again Nic. So, we now have a different solution that we're working toward... We are experimenting with assigning 'components' to a story in order to manage the various different skillsets that must contribute, and banashing subtasks completely (I hate them now!).

For example, the 'email' story I described above could have the 'design' component assigned, which tags our lead designer to design the email template, and a 'marketing' component that tags our marketing team to draft the email text content.

These implementers can then filter by component type to see what work they need to do, and then delete the component when they are finished with their part. (Sort of like a wonky checklist).

The lead engineer would still own the overall story, and thus they wouldn't need their own component... they are simply expected to implement the whole story.

Thoughts?

Nic Brough -Adaptavist-

Well, apart from finding sub-tasks an immensely useful way to break up larger bits of work... ;-)

Yes, that's pretty much a good way to go. It's not quite what components are intended for, but it's an imaginitive and useful way to do it. I was thinking of something similar on the train on the way home - labels instead of components, but I think it'll work better with components if you don't really have a solid use-case for components themselves (and you can always use labels as a partial replacement for components!)

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-software

jira-software-cloud