The story points can be used for estimate user stories and tasks will be marked in hours in Visual Studios.

When there is a critical bug (which is not in the backlog, reported by users) we incorporate to the current sprint and try to resolve it within the current sprint.

In doing so, we have to make adjustments to tasks or other issues, which,in turn will probably end up in a future sprint.

Now when we want to estimate for the critical issues reported (on TFS), we can enter the effort in hours. But, this does not display in the charts and nor it is counted. I figured that, if I was to monitor the effort for bugs, I have to create them as tasks and then only I can monitor on the charts.

My question, is do you recommend this approach or is it there something that I am doing wrong?


1 Answer 1


The short answer is: Bugs are drag, don't assign points to them.

The long answer is: The key idea behind story points is that they represent business value. The question is, how much business value can you provide each iteration, a value that is used to interpolate into the future. All things that don't provide any direct businesses value, writing TPS reports, safety training or going to trade shows are not assigned any story points, this is considered project drag.

Bugs are technical debt. You where able to ship X amount of story points in the past, but only by adding technical debt, now you are repaying that debt, which will mean less story points this sprint. This will reduce the projected velocity, but that is correct, since it adds the dept you tend to pick up over time into the equation.

The best way to tack bugs is in absolute numbers separate from the velocity. Yes, there are bugs of different severity and effort, but they should average out. Your goal should be to never to release bugs, if the number of bugs is high you should look into your QA processes and refine them. (unit tests / Code reviews / manual tests) In TFS a open bugs and a history of open bugs should go right onto the project dashboard.

  • 2
    See Feature Velocity vs Capacity-Based Scheduling. The idea that velocity should only measure business value rather than capacity is an oft-repeated meme by business adopters, but almost never by experienced agile practitioners. Don't treat bugs as invisible work. For more on what to do instead, see pm.stackexchange.com/a/26026/4271.
    – Todd A. Jacobs
    May 6, 2019 at 15:40
  • Thank you for discounting my 7 years of PM work experience. (I know it's ironic to be PM on agile projects, that's how we roll.) As an experienced agile practitioner, I quite seriously believe the velocity = business value / time. It's ironic that we went from tracking effort in ideal hours, to value and now the pendulum appears to be swinging back to effort. Bugs are drag on the project, like all other externalities you can't really control, like mandatory wild koala appreciation training. You should only put story points on the things you can control.
    – rioki
    May 10, 2019 at 12:37
  • 2
    Other opinions exist, but your views on what story points are supposed to measure aren't widely shared among leading practitioners. Mike Cohn, who isn't infallible but literally wrote the book on story points, repeatedly drums home that story points are not intended for measuring business value. See The Problems with Estimating Business Value and Story Points Are Still About Effort for just two examples.
    – Todd A. Jacobs
    May 10, 2019 at 12:57
  • If my memory serves me well, Extreme Programming predates most methodologies and they defined project velocity as user story / iteration (averaged). No mention of bugs or points. As someone that was trained on classical PM, i find it ironic that people are trying to address planing anxiety by similar means that put the Gantt chart into PM for software projects. Yes, you can put points or hours onto bugs and chores, but what do you really gain? Especially bugs are totally unplanable, just treat them like a leak in the roof after a severe storm.
    – rioki
    May 10, 2019 at 13:21
  • 2
    This answer is completely wrong. Bugs are work. Work is story points. Moreover, fixiing bugs may add busines vvalue.
    – maze
    May 11, 2019 at 16:52

Not the answer you're looking for? Browse other questions tagged or ask your own question.