3

Our team has just started using JIRA. Now we are looking for advice on how to build our process in the most convenient way.

We have stories to be implemented in further sprints as well as bugs to be fixed.

The question is how should we approach those bugs. I see following options:

  1. Assign bug to a developer
  2. Create new story for bug fix

While the 1st option is the most obvious, it is impossible to estimate a bug in story points. And also bug can be reopened in future.

The 2nd option looks like overkill as we creating two almost identical issues.

I would very much appreciate your advice how to build our workflow. thank you!

migrated from stackoverflow.com Dec 9 '16 at 23:17

This question came from our site for professional and enthusiast programmers.

2

I'm not sure there is a "right answer" to this, but even though you might not know how long it will take to fix a bug, you are likely to know how long you are willing to spend on it (would you spend 1SP on it? Sure. would you spend 100SP? Only if the bug is "all data just went poof").

So you can assign story points that answer the "how long am I willing to look into this bug until it is fixed or I know more about it?". Say 4SP. The outcomes then are either:

  • It took 4SPs - great, everything is perfect and you are the Guru of All Estimation

  • It took 1SP - great, either adjust the SP estimate retroactively or just pull another story forward to compensate.

    • After 4SPs you realise it's going to take another 20SPs to fix it properly. You open a ticket for the actual fix (which you know know what it is) and place it as a blocker to the bug ticket. When that is done, you can close both. Or, if your process allows this, you can just adjust the SPs on the original bug up to 20 and reload that developer's sprint.

There are certain reporting situations that do not allow the retroactive adjustment of story points, but unless you are in one of those, there is no reason not to take advantage of the flexibility.

1

There are many options here. Ultimately, you do need to find out what works for you and your team.

My take is that stories and bugs should be top level tasks. JIRA supports having types of tickets, and giving different types of tickets different fields associated with them as well as different workflows. Stories and bugs may or may not have a different workflow, but I do suspect that it would be similar, if not identical.

For bugs, I would have a ticket type of Bug or Defect. This ticket would be assigned to a developer to fix and test as necessary. After it is fixed, and unit tests are updated, what happens depends on your process. If you ave an independent test team, that team should also be looking at bug fixes as well as new stories. If new functionality undergoes acceptance testing, there should be acceptance tests associated with the bug fix.

The thought of reopening a closed bug is wrong to me. Once a developer has fixed a bug and the fix has been fully tested, accepted, and released/deployed, that ticket should never be reopened. If there is another change needed, a new ticket should be opened to either represent a problem in functionality or new functionality needed.

0

In situations like this, I usually ask myself a series of questions such as:

  • How will we estimate a new story added for a bug?
  • How will we QA and release a new bug not attached to a story?
  • How will we track any new bugs introduced by the bug fix?

References

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy