Are you in the loop? Keep up with the latest by making sure you're subscribed to Community Announcements. Just click Watch and select Articles.

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!


Finished but non released ticket

Hey all, how do you please track finished but non released ticket, that has to wait (for example till another ticket)  to be released?

The problem is, that: 

- sometimes it has to wait so long, that we have to move this ticket to next sprint (althought it is finished but waiting)  and than  ticket distorts velocity of sprint (counts in story points) . 

The problem  is getting bigger, when we have more tickets than one like this. (biger distortion, a lot of "needles" ticket in active sprint etc. ) 

Can you share with me, how do you solve these situations? 

Thanks a lot!


2 answers

0 votes
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.
Nov 11, 2023

There's a number of things in this, but I think it mostly comes down to your processes being not quite right.

Strictly speaking, an issue simply cannot be completed if it has dependencies.  In most cases, a Scrum team would simply not select it for a sprint until the dependencies are done (unless they are certain the dependencies will be dealt with early enough in the sprint to allow them to complete it).

But that's an aside to your case, you are not looking at dependencies.

I think the flaw in your process is looking at the wider picture in your Scrum teams, instead of their process (which they should determine, not have it dictated).  You need to look at just the team's process, not everything in one go (although you will probably want a combined view for some people)

This example is a bit more complex than your case, but it is trying to show that each team needs to look at a different thing.

Imagine three teams - devs, testers, and operations.  The intended flow through the workflow is: 

New -> in-dev -> dev-done -> in-test -> test-done -> deploying -> released

Set up one scrum board per team, with columns containing status as:

  • Operations
    • To do: Test-done
    • In progress: Deploying
    • Done: Released
  • Testers
    • To do: Dev-done
    • In progress: in-test
    • Done: Released, Deploying, test-done
  • Developers
    • To do: New
    • In progress: in-dev
    • Done: Released, Deploying, test-done, in-test, dev-done

The important bit is the "done" thing - it is different for each team!  One team's Done is another teams To-Do.  "Done" is an over simplification, it does not mean "no more work needs doing on this at all", it means "the current team does not need to do any more work on this".

The reason we keep showing all the "done" status to developers is that while their done is "dev done", their velocity is reported by column, not by status, and the issues must be on the board.  You need to have the developer board show all issues that have moved past dev-done

0 votes
Michel Neeser
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
Nov 09, 2023

Hi @Zuzana Prochazkova

In my company, we handle it like this: A development ticket gets closed as soon as it is tested in our QA system and if the definition of done is fulfilled. So, we close the ticket usually before it is actually released to production. But, every development ticket is assigned to a version in Jira which includes everything regarding the next release and therefore provides the big picture.

In other words: We use the version feature of Jira to track the actual releasing of tickets and close the tickets itself as soon as their development is finished.

Hope this helps.

Suggest an answer

Log in or Sign up to answer
Site Admin
AUG Leaders

Atlassian Community Events