Using the Scrum process template in RTC, what will happen if we add Story Points (complexity) to Defects?
Hi there,
We've had some users requesting to have the Story Point field (complexity enumeration) applied to the Defect work item type. (They cite that defects are just like stories, so they should be estimated that way.) How will this affect the rest of RTC (reports, dashboards, etc.), assuming we are using the out-of-the-box Agile Scrum process template? Will there be any harm, as we have many more users that are accustomed to not having Story Points on the Defect and want to keep estimating with Hours.
Thank you,
Donna Thomas
We've had some users requesting to have the Story Point field (complexity enumeration) applied to the Defect work item type. (They cite that defects are just like stories, so they should be estimated that way.) How will this affect the rest of RTC (reports, dashboards, etc.), assuming we are using the out-of-the-box Agile Scrum process template? Will there be any harm, as we have many more users that are accustomed to not having Story Points on the Defect and want to keep estimating with Hours.
Thank you,
Donna Thomas
Accepted answer
Well,
Since you add the SP fields on Defects every indicator (on plans) that counts story points with consider the defects estimate. So, with you have defects as children of a Story, and both with different estimates the plan you sum all and give a false estimate value. For instance, imagine you have a Story estimate with 8pts. If you have a child defect estimate with 5pts, your plan will show that you have 13pts to do on the current sprint. It's wrong view, since the effort to implement the story already counts the effort to solve the defect.
Comments
Complimenting...
On the Default Agile Scrum Template, defects should be small problems on the solution. Not an item that needs to be analysed, specified and so implemented like an story.
you haven't seen some defects then.. some are worse than the actual development, and consume resources.. we had a number of teams that treated defects like stories, cause they had to.
also, lots of defects come in AFTER the story is completed, so they would be placed somewhere else. and how would you 'estimate' some defects worth of points in the parent as a child of a parent created a long time ago (yesterday or earlier). this gets really twisted after a while.
One other answer
the problem is that Defects can be two different kind of objects, depending on your business process.
they can be used like stories (plan items), added into the backlog, sized, planned then broken into tasks.
OR
they can be tasks (execution items). but tasks do not have story points, and do not rollup like stories.
tasks are not shown in burndown or velocity. only plan items.
the default system config has defects as tasks. you can change it. but it is project wide.
they can be used like stories (plan items), added into the backlog, sized, planned then broken into tasks.
OR
they can be tasks (execution items). but tasks do not have story points, and do not rollup like stories.
tasks are not shown in burndown or velocity. only plan items.
the default system config has defects as tasks. you can change it. but it is project wide.
Comments
gunvansh khanna
Dec 29 '15, 2:00 p.m.For some reason we added SP field to defects, but the SP do not reflect in the metrics or widgets such as velocity, burndown etc..