Single Ticket Project Management

[ClassicVibe]

Our scenario is a common one, where a business "ask" is conveyed in the form of a ticket. From that ticket (1), analysis will create a narrative (1), and then break out smaller stories (2) from which implementation team will create tickets to code the story (3).

Narratives are complete when all Stories are fulfilled.

Stories are complete when all story-coding tasks are complete.

A single ticket allows the business to track time and related issues very easily, the problem of course is that it looks to me like we need a sub-subtask to accomplish this at the ticket-level, which is currently not available unless using a plugin (3 levels to accommodate).

Parent (business ask at epic/narrative level)

Child (Analysis Story(ies) from epic)

Sub-child (dev task(s) from analysis story)

The reason we are not interested in taking this up to a project level is because these software projects are created very often, they are just big tickets, and the management behind creating a new jira project for each would be painful.

Tickets (business asks) are created by the business, without understanding of scope or implementation effort, the tickets originate as a simple "ask" and scope and implementation gets worked out down the line. In other words, We need to make ticket creation as easy as possible for the business, and still accommodate all the implementation down stream.

Some tickets (like 90%) will be the actual story and maybe require a couple of coding tickets, but others will be a very high level ask that needs a full analysis and many coding tickets. So the long of it is, how does your company accommodate this type of succession, or how do you hack the system to get around it? It seems ridiculous to buy a plugin (like Structure) because I should be able to figure this out, but so far, I have not found a good solution. Simple ticket creation and time to the project are the big asks.

[twong_atlassian · Accepted solution]

Hi John,

Bunch of different ways to do this, some requiring commercial plugins.

Subtask of Subtask feature request: https://jira.atlassian.com/browse/JRA-4446 TLDR: Atlassian doens't have this on roadmap in next 12 months.

Sticking to your description, out of the box, you could clunkily implement using links in a creative manner. Since you can define arbitrary issue links, I could imagine doing stuff like "Creates the story" and "is the story for" and such. Clunky. Not the best solution, considering you want this to be business centric and semi intuitive.

You mentioned a solution: Structure. It directly solves your issue in allowing a n-level hierarchy.

I'll propose a third JIRA only solution: You could use greenhopper. The main issues are epics, the stories are stories, and the implementations are subtasks.

<runs away from pitchforks>

I think the stronger story is to use Confluence as a business centric tool to develop stories, and then, when the story gets granular enough, utilize JIRA as the tracker.

I think of the story thusly:

Bob and team works on the widget project. There exists a widget space in Confluence and a widget project in JIRA. Bob works with management and develops a story for version 2.0 of Widget, the overarching stories are there, with links to all the supporting documentation like charts and graphs and case studies that people want widget to be able to support gidets or whatsits. You use comments and tasks lists as lightweight tracking until you need to get granular enough to track it in the business cycle.

The main stories are thrown into JIRA (level 2), and the subtasks are the dev work (level 3). The people who are most used to working in JIRA get to stay in JIRA and get the main benefits of the workflows and such, whereas the ideation and creative elements can work in a more collab space.

[Natalie Hobson]

2nd the recommendation for GreenHopper - Epic > Story > Sub-task functionality should give you most of the functionality you desire.

Structure is awesome, but would only recommend it if you think it will be widely used - any projects that are associated with the plugin will automatically have a "Structure" section in all issues of those projects, which can make for an ugly issue view.

[ClassicVibe]

Thanks, both of you. I have been out of this process for a while, and hoped something had changed. I did use this as my impetus to finally go in and get Greenhopper hopping. I am a big fan of the confluence intetration, using that Confluence narrative as the jumping off point for sorting the large stories. In this case I am using all the recommendations.

The business makes a request in the system.

Various groups give their initial approval of the ask.

Analysis writes up the high level narrative and attaches to the task (parent(epic)).

Business Owner reviews updates and changes to the story as updates are represented on their Jira dashboard (capturing status and other changes to the ticket) giving input to the confluence Narrative as necessary.

Business and Analusis agree upon Narrative.

Analysis proomotes the status of the Narrative (Epic) which allows it to be viewed by implementation (Greenhopper), and shakes out the stories in confluence, and once complete, goes to greenhopper (painfully-stories (that roll up to the Epic) can only be created in Greenhopper?) and creates the story issues and links to the new confluence story.

Developer creates implementation sub tasks.

Product manager graduates Epic once all stories are complete.

Something like that anyway. The moral of the story is, thanks for helping me shake it out. Really, I was hoping you would give me a reason to not go through all this, but here we are, and it works pretty well for this place. Thank You

[twong_atlassian]

Glad to be of help!