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.

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.

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.

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:

• With agile, what do when a user story doesn’t get completed in an iteration?
• How do you keep track of a requirements document on an agile team?