nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Issue Type BUG Story point don't show up in Product backlog but shows in the story

DPA_lfx5j8

Hello,

For the Issue type Bug, our team reported that the Bug does not allow them to add story points to it.I was able to fix it( admin->issues->custom field adding the Bug to the custom field).

The issue which we are facing now is that although the story points appear in the Issue type Bug(as circled below), but don’t show up in the product backlog list(see below, second screen shot).

Due to this the team effort done on fixing the Bug are not counted towards team velocity.

Is there any config changes which needs to be done to display Bug Story point show up in product backlog list.

Accepted answers

All comments

Nic Brough -Adaptavist-

My guess is that your bugs are sub-tasks? Where you should not estimate, because Jira ignores it.

Thomas Deiler_db00h3

Dear @DPA,

Nic is right, if they are of type "sub-issue".

But anyway, as the name "Story Points" already says - its for Stories (plan able things) only. Otherwise they would be named "Bug Points".

It absolutely makes no sense to estimate bugs. The nature of a bug is, that it already exist and is making your business not working as expected (loose of money, ...). So in the end, a bug is the result of a not well implemented story, that was already estimated.

My advice, block some time (10% - 15% - that depends) of your sprint, to care about bugs, that the product owner has prioritized and don't waste time on estimating them.

So long

Thomas

DPA_lfx5j8

Hi Nic, The bugs are not Sub-task. The bug is at the issue level and shows up as independent on the sprint board.

Nic Brough -Adaptavist-

Could you give us a screen shot of the backlog showing stories with the estimate and missing from bugs?

DPA_lfx5j8

snapshot- jira.PNG

Raymond Mancy

I'd disagree with your assumptions. There are bugs, and then there are bugs. Some bugs make your business loose money, some don't. Some are easy to fix, some are very very hard. Some you don't even want to fix and will just close them as WONTFIX.

When planning a Sprint, the estimated complexity of a Bug (i.e Story Point) can often play a part as to whether or not it gets included.

Thomas Deiler_db00h3

Dear @Raymond Mancy,

the team earns story points for every item (that ideally has a value for the company) they finish within a sprint. This will result in a velocity.

A bug is the result of a false implemented user story (to simplify this assumption).

If they earn story points for fixing bugs, they get somehow rewarded for producing bugs.

When bugs are treated as user stories by giving them story points, the velocity of the team will stay more or less constant when they fix it and burn them down.

For observers this looks like a well performing team. In the end they delivered less than before - or in other words: less value.

When the teams don't burn the bugs down (fixing in sprints, but not counting the SP), the velocity will decrease. This is a more precise approach of showing the "truth".

To avoid this behavior - just do not add SP to a bug. Prioritize them and add them to the sprints.

The complexity may not have an influence on the planning. More important is the severity - how much it hurts. There is no relation between severity and complexity of a bug. So if it is e.g. a blocker it doesn't matter if you have estimated it or not - the quest is to fix it.

Estimating costs time. It's more productive to invest this time in fixing.

So long

Thomas

Raymond Mancy

Hi @Thomas Deiler

TL;DR; Ultimately what I care about is prioritisation and understanding capacity. To disregard bugs, spikes, tasks etc takes away from planning my Sprint because my velocity is all over the place depending on whether a Sprint includes bugs etc. and makes velocity as a planning tool meaningless.

The idea that you just 'prioritize bugs' just doesn't work like that. I need to understand their severity (let's call that priority) and their complexity. Why? So then I can plan the Sprint. That's pretty much Scrum 101. It's unfortunate that 'Story Points' has 'Story' in the word. Story Points is a way of measuring complexity, and Bugs, Spikes, Tasks all have measures of complexity and suck up resources (just like User Stories).

To your comment of 'a false implementation of a User Story', that is not what a bug is (sure, it *can* be sometimes). Hitting your max write throughput on your DB server during infrequent heavy periods has nothing to do with a false implementation of a User Story.

Velocity is not about being 'rewarded for producing bugs' or anything else, otherwise velocity would be a measure of nominal output (which it certainly isn't, hence why you would not compare velocity between different teams). Each team eventually settles into its own feeling for Story Points etc. You can have a team with a velocity of 100 have far less output (of any kind) than ones that do 50.

Story Points and velocity is about understanding capacity and trying to become predictable in what can be done within a Sprint. If bugs are excluded from this process then you're setting yourself up for failing in this regard IMHO.

Cheers

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira