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

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

User story vs function (aka use case) in Jira


Previously I've only been working in one team, but in multiple applications. Now I'm split between two teams and multiple applications per team and the teams are working a bit differently in Jira, but both are having a Kanban approach. Most of the team's work is to make a transformation from paper to digital so most of our applications are electronic forms the user fills in and at the end they sign it electronically and then it gets emailed somewhere. Historically we've always worked with the following Jira distinctions.

Never moved on the board
Epic: A container for stories of a similar type (ie Accessability, Input fields). These have not been moved through the board as these containers have been static over time.

Moved from column to column on the board ("Ready for UX" | UX | "Ready for dev" and so on so going through all sub-teams (UX, AD, Dev, Test) of our team)
Story: A use case (ie "Step 1 of the form") with requirements written like "Given X When Y Then Z). Basically its always an action the user take (press the button to go to step 2 of the form) which will make the system do something (display step 2 of the form)
Sub-task: One for each field under "Step 1 of the form" with requirements written like "Given X When Y Then Z)
Bugs: Even though these usually skip UX and AD

Moved from one sub-teams columns to Done (ie Ready for dev | Dev | Done)
Task: Anything that a sub-team is responsible for, but don't need any action in other sub-teams (Set up a repository, Talk to UX Lead about new icon standards)

Outside of the issuetypes we use
* Component: Name of the application (Survey X)

* Fix version: For Survey X it would be something like "SurX 1.3.2" (1 for major change, 3 for minor change and 2 for hotfix). Low number of hotfixes = quality in what we realese.

What I've missed in the structure above has been the user stories (ie "As a user I want to send survey X to HQ"). Reading through the Atlassian forum it seems like some are using the Epic issuetype for the user stories (Thread "Epic vs Story vs Task"). That way the Epic goes through the board, which seems nice as it gives a symbolic value. It think it would help with setting up functional testing as you can map that to the Epics.
Spontaneously I don't see a problem with using labels for "Accessability", "Input fields" etc.

Before I commit to the idea it would be nice to get some input from the community and how you look at these issues and which fields you use to help make it easy to find old issues.

Best Regards,



Log in or Sign up to comment