Ticket Solving Process at a Small IT dev Company

Information

• Project name: Ticket Solving Process at a Small IT dev Company

• Class: 4IT496 (WS 2018/2019)

• Author: Bc. Jan Mandík

• Model type: Discrete-event simulation

• Software used: SimProcess, trial version

Problem definition

There is a small IT company, which developed an IT Product (an email client) a long time ago. Today, customers or QA personnel report bugs, which are then analyzed by testers and given to developers to fix. After fixing the issue, the ticket is given back to testers to test the solution. The time required to fix the bug is extremely long, as there are not so many developers and the bugs are often difficult to fix. A single developer spend only three hours per day fixing the issues, as he spends most of the time developing new features of the program. The company management wonders how many full time ticket-solving only developers would be needed to fix the issues at the same pace as the issues are being created. As to the other parts of the ticket life cycle - testing and retesting takes neglible amount of time compared to the development time, it is however an essential part of the process.

Aggregated real data

The company uses a very simple setting of Jira ticketing software. It is possible to export data to CSV from Jira. In this export, there is a number of columns, most of which is useless. The columns I used are Created Date, Updated Date and Status. Status Column can have values ToDo, In Review, Done, In Progress. Out of these, only items with Done status were used, as only these have usable Updated Date. Updated Date present time at which a tester marked this issue as done. Created Date present a point in time in which the issue was created (after its analysis). Out of these points in time, it is possible to get numbers of created issues per day and difference between time it was created and the time it was marked as Done (in hours). The distribution of these values seems to be random, but I have Simprocess in-build ModelFit function to describe these distributions mathematically. The distribution of created issues per day seems to be Hyper Exponential Distribution and the distribution of hours in repair is Gamma Distribution. These are the expected distributions for this type of input, and simprocess ModelFit function was able to provide the best possible parametrs. The CSV file with has 345 usable lines. Those are all the tickets that have been marked as solved in the company's Jira since the Jira system launch. These 345 are enough to provide a distribution that allows the model to resemble real life workflow. Given the fact the developer currently works on the issues 9% of the time of the week, a have multiplied the differences between created and updated by 0.089. As to the analysis and retesting, these are not visible in the Jira. As I was the only employee responsible for these process, I have a good overview of how long it takes and I have used normal distribution to define these.

Model

The model is very simple given the company small size and the low level of Jira implementation. The model consist of one Generate Stage, three wait stages, and one Dispose Stage. The stages are described below: Generate: Simulates the real life inflow of new tickets from customers. Based on 345 cases, the inflow is defined as Hex(0.203, 1.632, 0.75) issues per that, that is is 0.56 issues per day on average. Wait 1 (Analysis): Simulates the analysis need to give the ticket to developers. It is simplified to take Nor(0.7,0.2,1) hours, based on my experience in this job. One tester is needed as a resource for this stage. Wait 2 (Repair): Simulates the repair process itself, which constitutes for most of the time. It is based on the before-mentioned date from Jire and the distribution is created by Simprocess from this date. It takes Gam(157.822, 0.597) hours - as you can see, this amount is truly neglible compared to Analysis and Retesting. Wait 3 (Retesting): Simulates the retesting necessary to marked the issue as done. It is a very quick process, it takes Nor(0.5,0.2,1) hours. Dispose: The issue is fixed and retested. The model is set in the year 2019, does not include issues that are already in the queue by the begging of the year. The most import output of the model is issues in queue/issues solved by the end of the year, based on the expenses.

Entities

The only entity is defect, that is not prioritized.

Resources

There are two resources. Its properties are based on the real data seen in the company: Developer: Needed for Repair stage. Works only on working day from 10am do 6pm. Costs 750 CZK per hour and 25000 annually. Currently there are five developers working 12 hour per week on fixing issues, but for the sake of simulation, I use developers that would work only on the tickets. Thus, 2 developers in the simulation are equal to the five real developers. Tester: Needed for Analysis and Retesting stages. Willing to work every day from 10am to 8pm because his utilization is low. Costs 250 CZK per hour and 25000 annually.

Results

For all the results, 20 replications were used to get the best data while not wasting too much time. With the setting that is currently in the company (2 developers working full time on ticket solving and one tester), only around 17% of tickets are solved, while other get stuck in the queue. This roughly correspond with the real-life situation observed in the 2018. On the current state, developer has very high utilization, while tester has very low utilization. The model could answer some interesting questions which could be used by company management: How many developers are need to reach 50% fixed issues per year? From what number of developers does their utilization go down? We will ever need a new tester? How many testers From testing various values of developers, we can seen that their utilization goes down? and so on. Answers to all these questions can be read in the report Logs, such as Media:Example.ogg