Given that sub-tasks go along with their parent tasks in a sprint, how are you supposed to handle burn-down when only a subset of those sub-tasks are expected to be achieved in a given sprint?
For example, I have a story that will be included in a release. I define the implementable chunks of work to develop the story as sub-tasks. Let's say there are 10 sub-tasks. Now what am I supposed to do if my development team only expects to be able to complete 5 sub-tasks in a sprint? I would have expected to put 5 sub-tasks in sprint 1, and put the next 5 in sprint 2. It would appear at the moment that GreenHopper will place all 10 sub-tasks in sprint 1, and thus the burndown chart will be based upon those 10 sub-tasks.
Can you help me understand how I should manage a body of work that is too large to be completed within a single sprint using the new GreenHopper rapid boards?
My suggestion in this case is to utilise the Epic function within GreenHopper to align larger groups of tasks towards a common goal. Epics do not share the same constraints that tasks or sub-tasks do.
Tasks and sub-tasks are issues within JIRA, and are subject to workflow constraints, field requirements, and other notions that apply to issue objects.
Epics are Labels, that get applied to each issue independently. As such, they have no attributes that would be required, no workflow statuses, no versions. They are not subject to inclusion in a particular Sprint, and are not treated as objects.
I’m a designer on the Jira team. For a long time, I’ve fielded questions from other designers about how they should be using Jira Software with their design team. I’ve also heard feedback from other ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs