Spliting the project

Eitan Mizrahi

Hello,

As I have read about AGILE, I saw that it is recommanded that I will create very small tasks (for 1 hour to 3 days).

Also that big tasks are not calling task, but stories, and small parts called epic.

 

Whether I am using stories->epics->tasks, how can I  connect stories to epics or tasks, and whether all the tasks are solved (or epics) - How is the related story is also closed (since issue is related to a specific story/epic/task, and I cannot relate them to story and task).

How can I see the whole process in graph.

 

I am a little bit confused of that herierchy, however I need some clarifications about what are stories, epics and tasks, and how can I combine them all together.

 

Thanks.

Nic Brough -Adaptavist-

The heirarchy is Epic (a huge tale), Story (a manageable tale), Task (a small piece of a story)

A story is the starting point.  They are often written in a way that tells a story about something a user might want, defining who the user is, what they want and why.  They're often written by the users too, rather than developers.

For example

• As a:  Progammer
• I want:  Bitbucket
• So that I can:  Keep my code safe and share it with colleagues

When you start to look at that story, you probably want to break it down into tasks such as "get hardware", "install bitbucket", "add users", "integrate with JIRA" and so-on.  These are the sub-tasks.

You might also have stories that are closely related to it and probably should be tackled at the same time.  So if you've got stories like "Install Bitbucket", "install JIRA", "Install Confluence", you probably want to group them together into an Epic such as "Get the main Atlassian stack for the development team".

In JIRA, it's a bit more complex and flexible.  Issues live in projects.  A Story is only one type of issue, and you can have many types of issue.  It's very common to see Story, Bug, Feature, To-Do item etc all in one project and handled at the same level. 

Epics are also issues in projects, but you have the ability to take a Story (or bug or feature etc) and link it directly to an Epic (which does not have to be in the same project).  That "epic link" groups your stories and issues into that Epic.

Finally, you have sub-tasks.  Again, you can define many types of subtask.  Sub-tasks are created within stories.  They are usually used to break up the work on a story into pieces that can be done individually or by different people at the same time.  (So a team would take on Story ABC-456, and create ABC-458, ABC-502 and ABC-503 so that Alice can be assigned the story and ABC-502, but Bob does ABC-458 and ABC-503)

When it comes to sizing these things, the best thing to do is estimate a story and see if it can be done in a sprint.  If it does not fit, then it should be split up into several stories, or converted into an Epic with more stories breaking it up.  Sub-tasks should not be estimated, they are purely for the team to break up a story into more manageable pieces.