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

[DPA]

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.

[Nic Brough -Adaptavist-]

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

[DPA]

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]

[DPA]

Hi Nic, above mentioned snapshot shows the Sprint backlog, where the stories have the story points but the bug created does not show with story points on the sprint backlog.

[Nic Brough -Adaptavist-]

Ok, that's perfect.  Could you check these two next:

• Nip into Admin -> Custom fields, and find the Story Points field - can you confirm that you only have one
• Go to HT1-162 and HT-163, and check they have Story Point values set

[DPA]

[Nic Brough -Adaptavist-]

Right, that's the problem - your bugs are using the wrong story point field.

You need all the issues to use the same Story Points field.

[DPA]

Nic, need further clarification here.

The first screen shot is duplication. All the issue types(Story, Bug etc..) are using the Story point field. We are using the ET1: Scrum Bug screen for Bugs and ET1: Scrum default Issue Screen for all issues.

Are you suggesting that we should be only using ET1: Scrum default Issue Screen for all issues for all issues including Bug.

Please clarify.

[Thomas Deiler]

Dear @DPA,

to user one screen for all issue or not depends on your further configuration. If they are same, stay with one screen. If you plan to change the configuration for stories and bugs, differently, then it's better to have two screens.

But be very sure to get rid of that duplicate SP field, so that there will be no more confusion. At least rename it.

So long

Thomas

[DPA]

Thanks Thomas.

Duplication was on the cut & paste and not on the Jira configuration.

The question remains the same. What additional configuration needs to be done to make Bugs Story point appear on Sprint backlog.

[Nic Brough -Adaptavist-]

Another test I need to do I'm afraid.  Could you go to the board configuration and look at the estimation tab.  I'd like to see what the list of options looks like on the drop-down (don't change it, just need to see a screenshot of the list after you click to get the list)

[DPA]

[Nic Brough -Adaptavist-]

Ah, not what I was expecting, but it answers it.

Your board is set to look at Original Story Estimate.  That's the column that appears on the right hand side adding up points. 

You need to put your estimates into that field instead of Story Points.

[DPA]

Thanks Nic. It worked.

For the best practices perspective, should the stories & BUG be estimated and displayed in the Original Story Estimates field OR Story Points. 

[Nic Brough -Adaptavist-]

Doesn't really matter which one you use, just pick one and use it for all projects in the board.

[Thomas Deiler]

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

[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]

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

[Thomas Deiler]

Dear @Raymond Mancy,

I recommended not to estimate in SP for bugs, only! I see no problem in estimating in hours/days. Then you can plan your sprint. Or alternatively, as described above: best effort (as much as possible) within a time box.

A performance issue is not necessarily a bug. Is a broken non-functional requirement.

So long

Thomas