It's all about the answers!

Ask a question

How User Stories break down should be represented in RTC?

THEONY MOUSA (111) | asked Jul 01 '13, 12:25 p.m.
For an Agile project the recommendation is to break down the set of user stories to smaller ones, containable into iterations. Although only the lower level stories are executable items, having the hierarchy in plan in RTC helps teams to see the whole picture of what they try to achieve and puts every small user story into context.
However the higher, non executable, stories should not represented in RTC in the same way as they will be picked up by the burndown reports and other metrics and add to the backlog of story points. What is the recommended way of representing this hierarchical view of user stories in RTC without impacting your executable items and reports?

3 answers

permanent link
THEONY MOUSA (111) | answered Jul 03 '13, 5:42 a.m.
Thank you all for your replies. I think what I should experiment using the plan items to give some structure around the planned work, but keep the stories as a flat list, all at the same level.
Geoffrey raises a good point about not be able to easily manage nested stories as stickies on a whiteboard; I will keep that in mind when defining the stories.

permanent link
Clement Liu (1.5k54249) | answered Jul 02 '13, 1:47 p.m.
Hi, Theony,
We're actually using plan items for those of  your higher level stories. Here is our  work item hierarchy for your reference. Hope it helps. Thanks.

permanent link
sam detweiler (12.5k6195201) | answered Jul 01 '13, 1:21 p.m.
stories are not executable items.. TASKs are executable items.

stories appear in Plans. (and if u ask, you can get the tasks too).
stories appear in Burdowns/BurnUps..tasks do not.
stories are complete or not.. no % done.

we created higher level objects.. Epic (work across more than one sprint) and Theme (work across more than one release).

we only sized stories.

THEONY MOUSA commented Jul 02 '13, 8:51 a.m. | edited Jul 02 '13, 2:33 p.m.

Sam thanks for the response.

Let me try to explain more clearly the structure I want to represent in RTC.

Story 1 -- broken into --> Story 1.1 ---> broken into --> Story 1.1.a
                                                                                 --> Story 1.1.b

                                  --> Story 1.2 --> broken into ---> Story 1.2.a
                                                                                 --> Story 1.2.b
                                                                                 --> Story 1.2.c
                                                                                 --> Story 1.2.d

Currently we enter into RTC only the lower level stories, i.e. Story 1.1.a, 1.1.b, 1.2.a etc
We are looking for a way that the higher level stories are also entered into RTC so we can get a hierarchical, logical view of what is we are trying to implement, without having the high level stories count into burndowns/burnups. Maybe the answer is as simple as we should enter them as stories in RTC but with zero story points (provided that this is allowed) or we convert them to some other type i.e. plan items and only the lower stories that we then size are entered as RTC "Story" WIs.
We are also using epics but at much higher level.

sam detweiler commented Jul 02 '13, 2:25 p.m. | edited Jul 02 '13, 2:34 p.m.

well... agile says 'Story' is a unit of work that will be completed in one sprint.
lower than that is Task (the actual work of the story)
above that is something else.

a story with a child story is really miss-using the system.

burn ups/downs are based on Story. this does not roll up child stories (cause there shouldn't BE any).
a story with 0 points will appear as part of the uncompleted sizing work.

Geoffrey Clemm commented Jul 02 '13, 4:05 p.m.

One thing to keep in mind is that some of the agile "best practices" are designed to address problems in tooling (or lack of tooling) ... so one reason to avoid having child stories is that it is hard to model with stickies on a whiteboard.  On the other hand, just because a tool makes it easy to do something doesn't mean you should do it (:-).  So in this particular case, one would want to identify what are the problems in practice of having stories that have child stories.   I have often broken a massive story (e.g. 80 story points) into a set of smaller stories.   In that case, I distribute most of the points into the child stories, but maintain a few points with the parent story, to reflect the fact that there usually is some work associated with pulling the child stories together.

Your answer

Register or to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.