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; } } }

What is the best practice for capturing debugging tasks in Jira that have to be done after release?

Chris deMontmollin_9o6bq8

Our primary goal right now is to make sure we are capturing the time spent on each story, and making sure each story is bite-sized enough that it can be completed in one sprint. This does cause problems when we want to keep a ticket in a specific sprint, but we need to QA after the change is released.

What is the best practice for handling this? Should we close the project in the sprint that the work is done and split out to a new ticket for QA and debugging? Should we leave the sprint open until QA is done and split out only if new changes are needed?

This is mainly an issue for our approval process. The only way we can close the ticket and move on to the split ticket, is by approving incomplete work. My hesitation in closing the sprint with incomplete tickets, is we will be unable to count that work towards that sprint.

Any help will be much appreciated!

Accepted answers

Ste Wright

Hi @Chris deMontmollin

There looks to be a few possible scenarios above:

QA is being completed for issues after the end of a sprint (thus the story is incomplete)
QA is being completed post-release

If it's the former, I would leave the story as incomplete in Sprint 1 and move it into Sprint 2 to complete QA. If an issue is incomplete, there's no benefit in closing it and creating a new ticket, as you're fragmenting the traceability of the full lifecycle of that story.

A sprint itself is a timebox where the intent is to complete all the stories - but if you don't, you still need to close it and move incomplete issues to the next sprint. If stories are moving between sprints and there is a bottleneck at QA, you need to identify this issue and work-out how to resolve it.

If it's the latter, closure does not have to equal release. You could class a story as complete within a sprint and release the version into production at a later stage. In this instance you could have a separate ticket for post-release QA and if a bug is located, raise it into the backlog populating the "Affects Versions" field to visualise where the bug was found.

Ste

All comments

Ste Wright

Hi @Chris deMontmollin

There looks to be a few possible scenarios above:

QA is being completed for issues after the end of a sprint (thus the story is incomplete)
QA is being completed post-release

Ste

Chris deMontmollin_9o6bq8

Hi @Ste Wright , thank you very much for the response.

The main issue we are trying to solve for is capturing the time spent for each issue in each sprint. We are not currently using story points and just going off of estimated time and time logged. The main reason we would like to split out tickets is to make sure we are recording the time spent in each sprint.

We are thinking that we will perform QA on live during release for tickets that need QA after being put on production. If there are substantial issues, then we will create a new ticket to debug those issues. If there are no changes needed, or if QA is complete before the release, then we will not create a new ticket or split out. Does this sound like a process you would recommend?

Ste Wright

Hi @Chris deMontmollin

That's an option - I'd usually advise:

If there is a time gap between completing a story and releasing it (eg. releases are only once a month), then close the story in the sprint and make the release as a separate entity. You might also want to raise a "QA" ticket in whatever sprint you're in when the release is made.
If there is no/minimal time gap between completion and release - i.e both are in the same sprint - then you should consider keeping the story open.

The second scenario doesn't stop you creating separate bugs though (linked to the story), nor closing the story during the sprint. It depends on your own team's definition of done - if done is classed as released but not verification it works, then that would make closing it acceptable.

------------------

In regards to tracking time per sprint, I'd consider whether there's an app which can help you achieve this view so it doesn't drive a decision on your ways of working - for example, Simple Timesheet & Worklog Gadget has a time spent per sprint view.

Ste

Chris deMontmollin_9o6bq8

@Ste Wright That all makes sense. Thank you for the recommendation on the app. I am in the process of seeing what we can do about investing in one of those apps, but do not have approval yet. Basically we aren't doing anything that we shouldn't do just to record time spent in a sprint.

The main issue is the number of times we are moving tickets to the next sprint, of which the original question is a part. Many of them are less than 50% complete for a variety of reasons. Your answers definitely helped get us closer though, so thank you kindly.