User Story versus Task in Jira

Question

I am learning about the agile/scrum process, and currently using it for a 6 month software project at my university. My team is using Jira.

I am starting to get confused between the difference between "tasks" and "stories".

I had thought that "story" aligns with "user story", which was one of the mechanisms we used to define our requirements. Each requirement on our project has a user story associated with it. I was told that the agile process is different because it keeps the "user" perspective in mind while developing. It made sense in my mind that a user story maps to a "story" in Jira. However, I read that in Jira Agile there is no difference between a task and a story.

My team has been creating subtasks for every story, but I was told this was wrong, and that our stories are too large and need to be broken down. For example, one story was "I want to be able to sign up for a free account to use the system". This obviously involves many subtasks. We ARE creating subtasks under the stories, but we were told the story itself is too big. How would I "break this story down into smaller stories"? A user wouldn't have a story about something technical, like "Set up a database server". I was told to make stories like "as a developer, I want to install a database server so that I can store new user information". This doesn't make sense to me, because we were previously told not to consider a developer as a user.

So, my question really is why is it wrong to create a story that consists of many subtasks? Is this just a choice that the team makes, or is there actually use cases for the difference between a task and a story?

Thank you.

Answer 1

There are multiple challenges on your question, let's try to consider the key ones.

First and foremost - what's wrong is what does not work for you. If it works for you to have several sub-tasks, why would it be wrong? There may be different way of doing this... but next time someone tells you "that's wrong", ask why it's wrong. And then, experiment. And compare. Be agile is to continuously improve, not to stick to rules that work on other projects.

Why is it a problem on having a Story with a massive amount of subtasks...

... from Jira perspective? You'll have a hard time when doing iteration planning. Jira does not allow planning at subtask level, so you either plan the whole story (with all sub-tasks) or nothing.

... from an agile perspective? If a Story is too big, then it should become an Epic. The Epic type also exists in Jira.

Side note on the difference between Jira Stories and Tasks: We have a rule of thumb in our project that everything that's testeable, should be a Jira Story (due to the story workflow). Anything that's not testeable, it's a task (or an Epic, or a sub-task, but let's make it simple).

Lastly, on the "as a developer, I'll install the database". Try to avoid it. Pick a single user story that needs a database. Define the minimal infrastructure for the minimal tables you need as part of this Story and go for it.

Answer 2

Much of what you're being told may not be wrong, but is missing some context at the least. First, we have to do a bit of defining to clear up term confusion.

Jira did not start as a project management or Agile tool. It started as a bug tracking / service desk tool. This carries with it some baggage we need to work around. Back when I started with Jira they actually called them all tickets. Then they went to tasks. In Jira, the term Task is just a work item - a request that someone has made to the team. Jira, being very versatile, lets you make more specific types of work items that have different fields and behaviors and as people started using Jira for tracking their work in Scrum more, it became common to create a type of work item called a "Story" or "User Story" to the point that I think the default config now has this. So that hits one of your questions - in Jira, a Story is a more specific version of a Task - they are both work requests and the Story was creating to help people who were tracking User Stories in Jira.

Now, on to those subtasks. In Scrum, there are backlog items (user stories are a specific kind of backlog item the way that in Jira Stories are a specific kind of Task) and these encompass the capability being asked for. They are the "what" of the feature and are usually understandable by a user. However, the team has to organize who is doing what and HOW the backlog item will be built. To do this, many teams create what we always called Tasks. Before we talk about this any more, let's clear up the ambiguous term. Because Jira already had a thing called a Task and it was not the same thing that Scrum teams called Tasks, they created this new thing called sub-tasks (which I personally think is a better name anyway). So, when Scrum talks about Tasks (and for the rest of this paragraph) think of the things that Jira calls subtasks. The sole purpose of the subtasks is to help the team organize there work, so there are some good practices, but no hard rules as the most important thing is that they are helpful to the team.

Now, User Stories can be too big, but the number of sub-tasks isn't a good measure of that. There is a good, if vague, rule of thumb is that it should comfortably fit into a sprint, which makes more sense from a risk-management standpoint. Many people interpret this as about 4 - 5 days max in a 2 week sprint.

Answer 3

Meh ...

Just go right ahead and define your "story," this being "your encapsulation of a hypothetical user's interaction with your proposed system." Absolutely define it – capture it – any way that seems best.

After all, "this is a user story," and a user cannot be expected to know – or to particularly care – how a system actually works.

Indeed: one of the key ideas behind "user stories" is that the "user" has absolutely no idea – and, absolutely no concern – as to the implementation of the system. Therefore, this "story" is not "distracted" by implementation-specific concerns: the "story-teller" describes the "story" as (s)he experiences it.

"So, is this 'story' an exact road-map to implementation?" No. Per contra, it is "an expression of 'the problem'" which has nothing to do with(!) "implementation." And that is precisely the point.

When you actually try to design and implement a complex technical system, you always run into "the hammer problem." That is to say, "whatever it is, it's a nail." So, the "user" represents a stakeholder who ... "is not a carpenter."

Answer 4

In order to put things in perspective and to establish what should be focused on, below are two highlighted differences between user story and task:

A. USER STORY. • User story provides business value

• A user story is something that an end user understands. That is, it makes sense to the user.

B. TASK • A task does not provide business values on its own

• A task is a technical or non-technical activity required to complete a particular user story and usually does not make sense to the user.

For example: As an automobile dealer I want these car collections painted in blue color So, they can attract lovers of blue color If this is a user story that gives value to the car dealer, then getting the blue paint to spray the cars is a task that the Auto painting team will perform as one of the steps to deliver value. Nevertheless, getting the blue color itself is of no value to the car dealer.