Need input on how to best plan with JIRA (stories vs sub-tasks)

Mattias Hallqvist May 13, 2013

Hi. We have some trouble finding a good way of using JIRA as a planning tool.

We're developing games and all games have the same foundation and framework so each project follows a similar pattern. Since we basically are our own customer it's hard to apply the scrum philosofy all the way.

Previously we used only stories, estimating them (by the hour) and looking at sum of estimates in agile view as a base for the planning. The problem with that is that the backlog and sprints easily becomes cluttered when there's loads of tasks and we'd like to wrap them somehow, so we looked at sub-tasks.

Once in an active sprint (work view) the sub-tasks and stories works great, giving us a better overview of different parts of the game. But in planning, the sub-tasks are pretty useless.
Reading up on scrum I realize that the idea is that sub-tasks should never be added until just before starting a sprint and that the planning should be based on stories. But we can't work like that, we need to resolve the sub-tasks estimates to understand how long it will take to finish a story. You could argue that you'd be better off not plan by the hour like that, but that's how we work right now and will do at least for some time to come.
I've also found suggestions that in such a scenario you can copy the total estimates from the sub-tasks to the stories to be able to plan. That may be doable but the problem is that we need to be able to filter our tasks based on if they are developement or graphics task, and one story may contain sub-tasks for both departments. We use labels to determine whether it's a graphics or development task but when using quickfilters, they only apply to the stories.

So. There's the scenario. If I put it the other way around, what we need is this:

- Being able to categorize our tasks (e.g. a story could be "Splash screen", with graphics subtasks "Draw splash screen" and development sub-task "Implement splash screen").
- Being able to plan based on summed remaining/estimates of all sub-tasks.
- Being able to filter the tasks during planning so that we can see the summed remaining/estimates for a certain kind of task (e.g. graphics).

I would really appreciate suggestions on a workflow for this. Is stories/sub-tasks the way to go? Could we use epics/stories instead? Is there a way to plan seeing all sub-tasks and the summed remaining/estimates at the same time?

Cheers

Mattias

2 answers

1 accepted

1 vote
Answer accepted
Mattias Hallqvist May 19, 2013

So nothing.

Well, I ended up using epics/stories instead. Works OK.

Radu Dumitriu
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
May 19, 2013

I only read your question today, but it's nice to see that you find yourself the correct answer. Just mark it as 'answered', please.

Mattias Hallqvist May 19, 2013

I wouldn't mind more input though since "Works OK" is not the same as "working perfectly". :)

Radu Dumitriu
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
May 19, 2013

Sincerely, I was about to give you the same answer, to use Epics / stories. You have solutions to sum up the story-points (or estimates, whatever you use) from subtasks at the upper level (well, we use our own poison to to this, JJupin). In the end, it all boils down to the level of sofistication / flexibility that is *bearable* by the user ....

2 votes
YC Lian May 19, 2013

Are you still using time estimate for your Story? It's recommened to use points to plan for your release (by velocity) and time (by hours) for your Sprint, or at least that's how I'm practising it.

Relevant links:

And yes, your use of Epic is correct. A Story should be finished within a Sprint, any thing greater than it probably is an Epic or needed to be broken into smaller Stories.

Radu Dumitriu
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
May 19, 2013

Mmmm, points? Not everybody will agree, that's for sure:

http://www.industriallogic.com/blog/stop-using-story-points/

YC Lian May 26, 2013

Not too sure where you got the idea that *everyone* would agree.

YC Lian May 27, 2013

And, just to make sure that you're aware. The link is not about dropping Story Points, it's about using relative/rough estimation to deliver real work and not missing the point of Agile (which is to get work done, not get Points cleared).

Suggest an answer

Log in or Sign up to answer