progress tracking time vs story points - complexity attribute for planning
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
>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"
yes, all those other things are work that people are doing. We have the same. we track everything in stories ans tasks.
|
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
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.