Spreading sub-tasks of an issue across sprints

[DART Team]

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?

[John Garcia]

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.