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
So nothing.
Well, I ended up using epics/stories instead. Works OK.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I wouldn't mind more input though since "Works OK" is not the same as "working perfectly". :)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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 ....
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Mmmm, points? Not everybody will agree, that's for sure:
http://www.industriallogic.com/blog/stop-using-story-points/
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.