Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

bugs during story testing


We are transitioning in to Jira from TFS. In TFS we used to log bugs during story testing. I know we can do the same in JIRA however  I would like to see what others are doing in Jira as far as bugs during Story testing. how are you logging it in Jira...for a bug and linking it to the story or something else?

I would like to know you methods for tracking and visibility on these bugs.

BTW we are trying to follow scrum agile




1 comment

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
Oct 08, 2019

I've seen two broad methods used for this.  The short versions are

  • Bugs as stories (sometimes in the same project the original story was in, sometimes in other projects)
  • Bugs as sub-tasks

If you are doing Scrum, the first option is a lot easier to work with in Jira.  This is because sub-tasks effectively add work to the sprint, and if that happens, you're throwing numbers off, and not being at all agile.  Even if you mangle some numbers (for example assuming that 20% of a sprint will be bug-fixing stuff found during the sprint), it fails - imagine you find a bug 5 minutes before sprint end - you've brought more work into the sprint and you're going to fail to complete it.  So bugs are easier to handle in scrum if you treat them as stories in their own right - you can plan them straight into the next sprint as new stories with a high priority.

Bugs as stories has some problems, with only a weak link back to the original story, you often end up having to group them in different ways, automating things like the fix version needing to be inherited from the original story and struggling to make sure they are all included in the right releases.

Bugs as stories also work better when you have people outside your development and test teams raising them (I like calling "bugs found by testing" "defects", whereas a "bug" is more likely to come from an end-user after you've released something with a bug in it), as the story approach for work not being generated by your scrum/development/design team is better.

Bugs as sub-tasks works better for Kanban and waterfall and others - you have a story, a bug is found the story is re-opened (or blocked from being closed until the sub-tasks are done - build testing into the workflow to keep it simple), so you keep working it until all the bugs are fixed.

There are merits in both ways to do it.  There are other ways as well, but I don't see many of them that are not variations of the two above.

Finally, if you are doing testing in Jira, I'd strongly recommend a look at the testing Apps you can get to add to it - they can really help track and trace tests and the bugs they can spawn (I do work for Adaptavist who produce one of these tools, but this isn't a conversation for any sales-spiel on that subject, so I'll leave it as "you should look for testing tools in the marketplace, and evaluate them to see if they do what you need")

Nic thank you for your comments. This info is helpful.




Log in or Sign up to comment