In IT business someone could say that tickets are similar to stars. Not because they are countless nor because of their romantic perspective, but because they are born, they live their lives until they finally die. The following text will describe a specific example of the life of a ticket. The birth of a ticket is connected to a problem. A ticket is a way to describe an issue. It can be about a bug, an improvement or a new feature. The issue is described shortly in the title with more details given in the description. It has a priority that determines its importance among the other tickets. Usually, a newly created ticket is not part of the running sprint (see the previous article about SCRUM). It waits in the backlog until the team decides the best way to implement it, and estimate how much time the developer needs to do the job. When its time comes, it is assigned to a specific person of the team and waits in the queue for the sprint manager to decide in which sprint it is going to be. Only when the ticket is about something really important, it is being discussed by the team right after creation and is assigned to someone to work on it immediately. Each ticket has a status that describes in which part of its life circle it is. Here is an example of the workflow that contains all possible ticket statuses. When a ticket is created the first status it gets is “Development ready”. It means that the ticket is ready for the developer. From this state, it can follow two different flows. The first is that the ticket won’t be implemented, and gives it the status “Done”. This means that the ticket is not needed anymore because the issue it describes is already fixed or because it is duplicated by another ticket. The second flow is that the developer starts working on it. This leads to the next status, “In progress”. When a ticket is in progress, it means that someone has started working on it. So every other person it the team knows that they should not deal with this ticket. While working on the ticket there are two possible flows. The first is that the developer may need to change to a different ticket. In that case, the ticket should return to its previous status “Development ready”. The second is that the ticket is ready and it should continue the next step of the workflow which is “Automation test”. “Automation test” is a rather literal status. It means that an automated process is run, that tests that the developer didn’t break anything while trying to fix something. The result of this process can be successful which leads to the next step, and the next status “Code review”, or failure which leads to “Issue found” status. “Issue found” means that something is not right with the ticket. Maybe it is not working as expected or maybe it breaks something, somewhere in the project. Either way, this status declares that further work is needed. When the developer decides to fix the issue, he changes the status to “Development ready” and then to “In progress”. “Code review” status means that the automated tests couldn’t find any problems so the code should be reviewed by another developer or the software architect. If the reviewer decides that something is not as it should, the ticket is rejected and this results to “Issue found” status. If the reviewer is happy with the code, the ticket is approved and proceeds to the next status, “Quality check”. When a ticket is in “Quality check” it is time for more testing. This time it is not automated, but it is done manually by a tester. When the tester starts testing, the ticket should have the status “Testing”. If everything works as expected the ticket is approved and gets the “Approved” status. If something is wrong, then it is rejected and gets the “Issue found” status. An approved ticket is ready to be merged with master. So what status could be more appropriate than “Merging” for this process? If merging is successful the ticket gets the “Merged” status and waits for the next release. If something goes wrong, the ticket gets the “Issue found” status. After a ticket is released to production it gets its final status, “Done” which means it is officially dead. So if I were in a ticket’s shoes, assuming that tickets have shoes, I would choose to be low priority and highly prone to bugs and issues, that would lead me to “Issue found” and extend my lifespan a little bit longer, while making someone’s life a little bit harder, hehe.

We are a software house!

A place that we gather all together to build, test and ship software for high demanding clients.

Our headquarters

Ipirou 16
Drama, 66100
Greece

T: +30 2521 105247
T: +31 (0) 20 894 6313
E: [email protected]