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; } } }

I have lots of user story and issues and I dont know how should really define them in Jira?

masha_yoosefinejad

how should I start to define issues in Jira? what is the first step? I want to know what is the most effective way to categorize issues? is it ok to start with epics or is there another way?

I will be thankful if any one has any related experience to guide me please?

Accepted answers

All comments

DPKJ

First create project, and then few component in that project.

Once this is done, create Epic and then Story and then Task and Sub-Task in Jira.

Project --> Component --> Epic -> Story --> Task --> Sub-Task

This is what I am following for more than 4-5 years.

masha_yoosefinejad

could you tell me what the component exactly is??? should I create it? I mean does it exist in default issues or not??

DPKJ

@masha_yoosefinejadComponents are sub section of project, they are not issue types.

You can look at this knowledge base article by Atlassian - https://confluence.atlassian.com/adminjiraserver/managing-components-938847187.html

Inactive Stephen

Hi @masha_yoosefinejad

I would suggest the Atlassian product guides are a good place to start - you can view these by clicking here

It's important to structure your work in the best way for you. The good thing is it's really difficult to do the wrong thing in Jira as it is designed to be flexible.

A few pointers which I find help our teams:

Project: Decide how you're going to use your project first - this is the housing your issues will live in. Is each project going to be a deliverable? Or will it be a product? Or perhaps it'll represent a team?
Components: Components are a sub-section or categorisation for a project - you might use them for squads or teams, or perhaps to visualise a set of stories which belong to a certain development type (eg. front-end, back-end, security).
Labels: Unlike components, these cut across all projects - so if we are using team projects should labels be used to group issues onto a board? Or perhaps to show MVP for a certain release?

I find deciding the basics can be a great way to start. Epics and stories - if you're using these already, you could create your stories first and link them to epics later - or create your epics and then add stories into them. Either way is going to work.

I'd advise reading the guide I linked to - some great information for starting your Jira journey

Ste

masha_yoosefinejad

Hi, thanks a lot for your complete answer and advice.

Could you please guide me more? Shall I create TASK for every story? and link them to the story or epic?

In my organization every story is related to a specific team.. For example a feature that the customer wants can be dived to 10 stories that each of them is related to a team. Teams members do their task and close them. In each sprint we can monitor which user story is not completed and why?

Do you think is it a good pattern or not?

masha_yoosefinejad

Thank you a lot

Inactive Stephen

Hi @masha_yoosefinejad

Your teams need to decide the best way for them to work - but here's some advice on how I break down work:

Epic: Large user story; a piece of work which requires more than one user or team to work on. The chunk of work will deliver a piece of value which is a building block to delivery of the overall product.
Story: Small, valuable deliverable which offers some customer or business value. The Story has acceptance criteria to verify "Done". These are worked on by individual team members or via pair-programming (XP).
Sub-task: Technical tasks split from the Story. Developers use these to show the steps to complete a Story - often used more for technical / complex builds.

^ We also have Features above the Epics - which are larger, releasable parts of the product. This is added as part of the Portfolio add-on.

I guess the difference is we use stories at a single user level - rather than Sub-tasks. Also looking at DPK's model we don't have Task between Story and Sub-task - we use Tasks for Technical BAU (so it's the same level as Story). We find this works better with the standard Jira hierarchy.

Ste

Welcome!

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

Quick Links

Find more posts tagged with

jira