It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Follow this question
Question details

×42,787
×1,207

question asked: May 12 '13, 12:46 p.m.
question was seen: 5,833 times
last updated: May 18 '13, 9:14 p.m.

Related questions

FAQ - How this Forum works

progress tracking time vs story points - complexity attribute for planning

0
Natalia Liaskovski (57●1●12●19) | asked May 12 '13, 12:46 p.m.
We have Story work items that represent new functionality and sized up by the story points. We also have other work that does not amount to new functionality or user stories. That work is represented by tasks, defects, other various work item types, none of which have story points attribute. The universal denominator across all work items is time (estimated, spent, corrected, etc. )

The issue is the planning  complexity attribute, which seems to be mutually exclusive.

Ideally one would like to see percentile of progress on the plans as it relates to all work - new functionality and non-new functionality related, in other words: overall progress.

The solution seems easy enough - just to set complexity to time. However, in that scenario setting story points to track progress is irrelevant - none of the story points translate to time. (then what's the point of having them?)

In order to track progress across stories one would have to set time estimates on stories in addition to story points - there is no built-in formula that would translate points to time nor there is a way to provide it (or is there ?).  Which makes story points kind of useless for progress tracking ...

On the other hand , if we set complexity attribute to Story points - all other work that does not have story points has no way of progress tracking. In that scenario - everything must be a Story, in order to track progress on plans. In addition to that, if progress is measured in Story points, all stories have to be broken down into 1 iteration duration - how else would you show that your Story has 3 ot 5 points complete ?

All in all in order to have a usable progress tracking in plans for both point based and time based progress, there has to be a way to define how to:
1) translate points to time so that we can see progress on all work - story and non-story related
2) a 'story points completed' attribute that would be taken into that formula

Is there a way to have it done in CLM 3.x or 4.x ?

2 answers

Most liked answers|Newest answers|Oldest answers ↑

0
permanent link
sam detweiler (12.5k●6●195●201) | answered May 12 '13, 1:23 p.m.
>We also have other work that does not amount to new functionality or user stories.

shouldn't ALL work fall under SOME story?  else why are you doing it?

Maintenence falls under the maint story, and u reserved some capacity to deal with it.
what is the 'other work'?  if it doesn't relate to a story somewhere, then you are really not using the system (Agile, RTC..) to manage your work properly.

some say 'defects' can't be sized or estimated.. phooey.. you KNOW how many you are expecting, or COULD know.. look at any prior software you built.. how many defects per story, line of code, task, ... its an ESTIMATE.
(now, your estimate might be wrong, in either direction, but so is the estimate on the user stories)..

stories and points for 'progress' is a measure of the teams ability to estimate. How close the burndown line is to the estimate is the key.. (and u also need to track unplanned changes to the work, shouldn't happen, but we all know the facts)

so, my answer is, all that 'other work' should be under some story(s) being tracked, else you have capacity being burned without knowledge and someday this will be the downfall of your project.
Comments
Natalia Liaskovski commented May 12 '13, 2:47 p.m.

separately addressing "other work"

Other work is all sorts of things - API adoption , various migration activities, things related to documentation ad/or testing activities, defects

Now, if defects fall under a story :), you would need to have them manually added as they queue up IN ADDITION to regular triaging. Normally if your defect has filed against and planned for attributes set - they will automagically show up in the plan. But according to you - you also need to add them to some sort of story. Well, let's say you do that - then how defect closing will affect story point progress on that story ?

sam detweiler commented May 13 '13, 8:01 a.m. | edited May 18 '13, 9:06 p.m.

yes, all those other things are work that people are doing. We have the same. we track everything in stories ans tasks.

>how does story ending affect story point progress?  it doesn't.

the 'maintenance' story is never completed til end of sprint. in RTC Defects are the same as Task.
you an change it to be like Story.  so you can see each 'end'. 

But as noted in the other topic, agile says 'stories' should be the unit of work that gets done in 1 sprint.
(we use Epic to contain work that is bigger than a sprint, so it has child stories)
and all stories have Tasks.. that is the real work.

0
permanent link
Geoffrey Clemm (30.1k●3●30●35) | answered May 18 '13, 9:14 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
The way I like to describe it is that a "story" is written from the end-user's perspective.   You then estimate the complexity in terms of a more abstract quantity like "story-points" because you haven't done the analysis that would tell you how much time it would take to implement ... and that time will depend significantly on what developers end up doing the work (different developers have very different skills and experience, leading to very different times to complete a particular task).   Once a particular developer is ready to work on a story, they will break it down into one or more tasks, where a task is described from a developer's implementation perspective.  Once you have a concrete development task, and a specific developer assigned to do it, you can then estimate the time the task will take.

As for work items that do not actually take up any work (but are more placeholders for information), one way to keep them from disrupting your load/progress calculations for a particular sprint is to not assign them to a particular sprint.

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.