Finished but non released ticket

[Zuzana Prochazkova]

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!

Zuzana

[Michel Neeser · Accepted solution]

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.

[Nic Brough -Adaptavist-]

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