Not really. Stories and bugs, though named distinctly different are both software development items. As such, the vast majority of activities and controls that we model for a story are applicable to bugs as well. The key distinction between stories and bugs often comes down to data.
Bugs should include Affects Version/s, Steps to Recreate, Expected Behavior, and Actual Behavior. Whereas with stories we're capturing the who, what, and why from a user perspective. How and when we require this data relies on what practices we're observing.
For teams using Kanban practices where there is a Backlog status and a Ready for Development status, the transition to Ready for Development can be used to capture required data based on issue type.
In this simple case, we would have two transitions from Backlog, Ready for Dev and Ready for Dev - Bug. For each transition, include a transition-specific screen to capture the appropriate fields.
Example: SDLC Ready for Dev - Bug Transition Screen will include: Affects Version/s, Steps to Recreate, Expected Behavior, and Actual Behavior in addition to any other fields needed in both cases. Leveraging your workflow conditions, you allow the Bug issue type to only use the Ready for Dev - Bug transition.
All other issue types can default to the Ready for Development transition by explicitly checking that the current issue type is not a bug.
The considerations above work well in workflow cases where you have gated controls as a function of status change. This might apply to teams that include requirements definitions and design efforts within the story or bug life cycle (as might be the case with Waterfall).
This logical approach allows for workflow reuse which has the added benefit of decreasing administrative burden and increasing process consistency.
Scrum teams view Ready for Development a bit differently. Good Scrum practices dictate that product owners will refine their backlog as items are prioritized upward. Refinement provides all functional details necessary for the scrum team to be able to work the ticket including validation of bug reports and associated details.
Once prioritized, the development team will review stories and bugs at the top of the backlog to make sure they understand the requirements. The work is considered Ready for Development at the moment it is accepted into a sprint.
We’re only scratching the surface! If you want to learn more about what Jira can do for you and your business you can browse our content here, or contact our team of experts and we’ll answer any questions you may have.