6

I am going to start a new project using Scrum and Jira and I have some questions regarding how to write proper tasks in Jira.

From what I understand user stories are small non-technical descriptions written by the stakeholders (ideally) that can have the form: As a user I want to order monkies so I can earn money.

However these tasks must be elaborated with requirements, technical requirements etc. My question is: How do you write such tasks in Jira properly, and do I have the right understanding of user stories.

Should I create user stories as super tasks and then create subtasks with the actual tasks/requirements?

Should I estimate super tasks/user stories, or only the sub tasks?

Improve this question
1
  • what version JIRA do you use? do you use plugins that customize it for Scrum?
    – gnat
    Mar 9, 2013 at 13:43

4 Answers 4

Reset to default
4

Should I create user stories as super tasks and then create subtasks with the actual tasks/requirements?

Yes, same reason as @superM gave. Our team actually puts all the acceptance criteria and requirements in the user story (super task) and then create subtasks to outline what exactly the developers need to do to accomplish that story (eg, create table, add service to do X, tweak server params, etc).

We also use the GreenHopper plugin for JIRA (http://www.atlassian.com/software/greenhopper/overview) to track our Epics and Stories in the backlog. Once the Stories are estimated with Story Points and committed to a Sprint then the team creates sub-tasks under each Story for what they will actually have to do to get the software to implement the feature. The GreenHopper plugin does a great job visualizing the sub-task to User Story relationship. However, even without the plugin, vanilla JIRA will let you specify a main task (call that your story) and then sub-tasks (what the team knocks out during the sprint).

Should I estimate super tasks/user stories, or only the sub tasks?

We estimate story points at the Story level only (the GreenHopper plugin adds a custom field for that value, but if you don't use the plugin you could create a custom field if you wanted). But on our team, as the developers complete their sub-tasks under each story, they log their work (eg, how many hours it took them) so we can report on it later. We never log work (hours) to the story (super task) and we never estimate the hours to complete the sub-tasks or stories going into them, it's always post-mortem in our case.

Improve this answer
4

Using hierarchy like Epic -> Story/Task -> SubTask works great with few exceptions:

  1. There is no way in JIRA to plan which SubTask the team committed to finish in the single Sprint
  2. If the Story/Task is BIG then 1 level of decomposition could be not enough
  3. In this way both Story and Task serve the same purpose and are interchangeable.

We go with a deeper hierarchy: Epic -> Story -> Task -> Task -> ...
Here Story is short for User Story, capturing requirements and own by Product. Task on another hand is the result of decomposition of the Story or another big Task and own by Development.

The only problem in this case is that naturally GH doesn't offer a way to define relationship between Story and Tasks. We are using Parent -- Child link, it needs to be maintained manually.

I saw a 3rd party plug-in defining hierarchical relationship between issues and reporting on consolidated Children to Parent estimates and spent time. I didn't use it, so won't mention it here for now.

Improve this answer
3

You have a very superficial understanding of user stories. That's fine, but you should know. If you really want to understand this topic, then I highly recommend you look at the work of Liz Keogh, Dan North, Chris Matts, and Jeff Patton. Have fun.

Don't overthink tracking this stuff in Jira. It's just a fancy to-do list. Here's a story. What's left to do? Put those tasks in Jira, each associated with the story. As people think of extra things to do, make these tasks in Jira, each associated with the story. That's it.

Improve this answer
2
  • This isn't a helpful answer. JIRA Agile has some confusing bits on tasks vs. subtasks and parent-child relationships.
    – Kyle Pennell
    Jun 4, 2015 at 16:29
  • Yes. Jira Agile is confusing, therefore my advice is to use it as lightly as possible, rather than shoehorn your workflow into its implementation. Jira agile is built for either the lowest common denominator workflow, making it hard to use for any specific purpose, or as a weak way to enforce a defined process, which defeats the very heart of agile software development. I can think of no more helpful advice than "don't let it suck you in".
    – J. B. Rainsberger
    Jun 6, 2015 at 16:33
0 
Should I create user stories as super tasks and then create subtasks with the actual
tasks/requirements?

Yes. It is very convenient because you can easily see why a certain task was performed. Besides, this approaches lets you to track the progress of every user story. 

Should I estimate super tasks/user stories, or only the sub tasks?

From my experience, the smaller a task is the easier is to estimate it. Small estimations also tend to be more accurate. The estimation of a user story is the sum of its subtasks' estimations. Thus the story estimation is more fair, accurate and sensible.

P.S. Here are some useful links on scrum and Jira:

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.