Guidance on using stories VS tasks

[Daniel Tan]

We are an application maintenance team and primary work on BAU support and implementing minor enhancements. We are not a software development team.

We use Kanban boards and not Scrum boards.

Could you please explain the difference between a JIRA story and a task and how they should be used.

Example 1 - Work item "Create report A". Should this be a story or a task?

Example 2 - In EPIC "Upgrade Application A to V1.1", there is a work item "Regression test Report A". Should that work item be a story or a task?

I'd appreciate examples of how you've used epics, stories and tasks in your JIRA project

Thank you

Dan

[Peter DeWitt · Accepted solution]

@Daniel Tan , There are so many ways of using this issue types. The crappy answer is that you can use them for whatever you want. However, here is a bit of advice from my years working:

task - something that takes minutes to complete

story - something that takes hours to complete

epic - the equivalent of a project containing stories and tasks. Takes days to complete.

-pjd

[Daniel Tan]

Thanks Peter - I'm always in favour of pragmatic solutions :)

[Valera]

Well, time criteria in defying the type of your work does not seem credible. Why would we even spend time on creating a new task that would take minutes to complete?

(User) stories are for feature and functionalities of the software being developed, bug reports are for bugs, tasks are for other project works, such as documentation, planning, reporting, prepare release, architectural design, database design, etc  Some of those can be subtasks to bug reports and user stories.

Developer tasks, user stories, product bugs.

[Jack Brickey · Accepted solution]

Technically, underlying Jira behaviors treat tasks and stories the same. There is no difference, it is simply a name. It is left to the users to decide when they use one vs. the other. 

Stories are traditionally associated with agile methodologies and especially scrum.   But you can just as readily use tasks.

[Daniel Tan]

Thank you Jack

[YOWfactor]

@Jack Brickey - if I wanted to keep things as simple as possible I'd tend to either only use story or task with sub tasks if necessary. A purely semantic differentiation could be to use story only for user stories in software development and task for (administrative) ToDos in any kind of project (like setup software xyz or organize a workshop). What do you think?

[Jack Brickey]

It really is personal preference but indeed for a true Software project I use Story for use cases for desired functionality and reserve tasks for issues that don't translate to modifying the product. For example - Review document would be a task.

[Valera]

(User) stories are for feature and functionalities of the software being developed, bug reports are for bugs, tasks are for other project works, such as documentation, planning, reporting, prepare release, architectural design, database design, etc  Some of those can be subtasks to bug reports and user stories.

Developer tasks, user stories, product bugs.