It's all about the answers!

Ask a question

Planning Stories and Tasks in RTC

shirit Kidron (111539) | asked Jul 18 '13, 4:36 a.m.
edited Jul 18 '13, 4:37 a.m.


I created a a story type work Item. The story has a few tasks related to it (Parent Child relationship). A few of it tasks are planned  in release 9(Sprint 1 in release 9) and a few in Release 11(Sprint 1,2 Release 11).

To which plan should I relate the story to? Plan 11 where the story ends? Product backlog ?

Can I view in some plan/backlog report all the tasks and there Parents , though the parents are not related to this specific plan?

2 answers

permanent link
Ralph Schoon (62.3k33643) | answered Jul 18 '13, 5:00 a.m.
edited Jul 18 '13, 5:48 a.m.
I guess the 'pure Scrum' answer would be: If you can't make the story in one sprint, then it is not a story, but an epic.
You want to break down your stories so that you can do them in one sprint. The reason is you want all work to be accounted for as story points in the sprint you spend the work. Which you won't get if you work in sprint A for something that is done in Sprint A+n. Not splitting up has impact on your velocity. You get a dent where you worked but had no story and a hump where you got all the points but did not spend all the work.

So you should make a story for the part in sprint A and one each for the parts in other sprints. Then you make an epic the parent. The epic tracks all stories which are planned for a specific sprint and track the tasks done in their sprint. "Pure Scrum" the stories and tasks remain in the backlog until the iteration starts that they are addressed. If you plan ahead I would plan the stories in the iterations they are supposed to be addressed. In the iteration planning they might return into the backlog (with a ripple effect on all other stories in later iterations).

The question is where to put the epic. 8-)
The epic would show as a parent of the story in the plan the story shows up. So you don't have to plan the epic for anything. If you do releases, I would probably plan the epics for the release which is one level up.

If you don't do it this way, I would plan the story for the iteration where it is supposed to be completed.

shirit Kidron commented Jul 18 '13, 7:49 a.m.


Thanks for the detailed reply.

Is the product backlog purpose for only temporary work items that will eventually related to releases and sprints or its a part of the hirarchy?



Ralph Schoon commented Jul 18 '13, 8:19 a.m.

In Scrum, the product backlog is the pile where the stuff sits that is not planned for the current sprint. The product owner ranks the stories puts them, ranked, into the sprint.
So the backlog is not really hierarchical. However, if you have multiple teams and a project area that run against the same backlog, there is kind f a hierarchy dependent on what plan owner you select.

You can also view the product backlog as tree using parent child, if you want to.

permanent link
Takehiko Amano (1.3k3741) | answered Jul 18 '13, 5:07 a.m.

From a Agile practitioner point of view, I recommend to split the story into two. One is release 9 story, and the other is release 11 story.  Create a link as related between two stories. Or create new parent such as "Plan Item" or "Epic".

Your answer

Register or to post your answer.