Granularity: Epics, Stories and sub-tasks?

[roam_scott]

I'm kicking off a new project, it's my first real agile project. Right now we have 4 epics. One of them is "Account System". Under that, I have a few stories like "As a user I need to be able to login". Each of the stories has sub-tasks like "Design login page", "Create Account Database", etc.

One of my problems is that I'm using JIRA and sub-tasks do not show up on the backlog. In general, I just don't know how granular to be. What would everyone recommend to categorize the "Account login" scenario? (Here is a breakdown of some example tasks)

└ Account System
   └ "As a user I need to Login"
      ├ Design login screen
      │ └ Add "save password" checkbox
      └ Design account tables

I'm starting to think the story needs to be the epic and the two design tasks need to be "tasks" with the checkbox as a sub-task. This would mean a lot more epics. I assume that's okay?

Any input would be GREATLY appreciated.

[Thomas Schlegel]

Hi Scott,

my opinion of this is:

an epic is defined as something that lasts longer than one sprint. It is a container for stories.

Stories should be ready within one sprint. You plan your sprint with stories, they have storypoints for estimation.

A task is part of a story. In my opinion, a task should be done in a very short time (one day), they are not estimated as stories are. The storypoints of a story should contain the efforts of all the subtasks.

That's why I think, tasks don't have to be in the backlog. There you plan your stories for the next sprint. Adding every task would result in a big, confusing backlog.

So, I would design your issues like that

• Account System (Epic)
  • Design Login Screen (Story)
    • Add checkbox (task)
  • Design Account tables

OR

• Account System (Epic)
  • As a User I need to login
    • Design login screen
    • Design account table

I think, "Add checkbox" is a little bit too small for a task.