4

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.

  • Hello Sabien! this seems a repeated question, have you checked this?pm.stackexchange.com/questions/16739/… In short I would say a story is not something specific and that needs to be broken down into tasks. Tasks are "units" of work. – Roberto Anzaldua Feb 13 at 1:22
  • I believe this question is slightly different, as it asks the relationship of the agile concepts with the Jira-specific concepts. – Tiago Cardoso Feb 13 at 1:39
5

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.

  • +1 especially for the last para. – DPH Feb 13 at 17:40
4

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.