About project management models in bugtracking systems

During the software development, the team can create the big number of tasks, fix the bugs and manage requirements. They are constantly discussed, their status is changed from one to another, they are measured, classified, issued to the assignee, grouped into version and linked with each other. The first thought coming to the mind is “hmm, is it necessary to use corporate bug tracking system and the order.” That’s right it is a necessary condition for the effective project management, but not sufficient.

Using any bug tracking system does not guarantee that your project will be in order. To keep everything under control, firstly you need to develop a certain “game changers”, which will be followed by your team. The rules should be balanced. They should not contain elements of bureaucracy, so as not to complicate the process and not to slow the team down, and should not have too high a degree of freedom not to create controversial and ambiguous interpretations of the same concepts.

Developing of «game changers» means to create a specific framework for managing tasks, bugs, requirements (or epics, user stories, and features). As part of the framework or model of management is necessary to determine:

  • Types of issues, we will manage;
  • Types of bonds, which we will use to link issues;
  • A list of attributes for each type of issues;
  • Life cycles with transitions states.

But this is only part of the problem because these components describe only the static model of management. Depending on the used methodology you have to answer the question «who will be?» and «when it would be?». For example, «when and who changes the task’s status into «In progress?», «Who links user story with epic?», «Who can approve and issue a bug in the version?» «When the tag should be assigned?». Also, if you want the model to be a holistic and sustainable you need to define a number of additional rules. For example,

  • No more than 2 tasks in «In progress» on one assignee;
  • Version and priority of the task should be the same version and priority as the sub-tasks;
  • The author of tasks estimation should be the same as the asignees;
  • The worklogs should be loged at the current day (at least at current day for the day before);
  • do not start implementation task before estimation.

Of course, I rely on my experience of those projects in which I’ve participated. Every case we have experienced and consciously made the decision in favor of one or another rule. But these rules are not a panacea. Analyze, what is critical in your case, and what is not, and consider the features of your projects. Please do it without fanaticism, do not lead to bureaucracy and clamping team on grips.

In this way we define the coordinate system, using which any participant understands “what”, “when” and “what for” to do.

JIRA system is one of the useful tools for the implementation of such task management frameworks, bugs and requirements. But if you don’t have a well-thought-out model and the “game changers” for large long-term projects, even flexible and multifunctional JIRA can easily become a “cesspool” and chaos may occur in the project. Why is it happening? As the rate of appearance of new information is very high and the intensity of the exchange of data between processes is also “off scale” at the stage of active project development. You need to learn new data very fast and decompose them but not just dump everything in one pile. For the fast interprocess communication you need to quickly find the relevant information, process and submit on purpose.

Analyzing the experience of participating in large projects, I may say, that the narrow spaces just are formed at the intersection of processes when they exchange information or when the processes face the external requests came from stakeholders, customers or top management. You should pay attention to this.

Let me give some examples:

1. Manager needs to understand “who and what tasks is doing at this moment?”. I don’t mean that you should to collect a meeting or come personally to everyone. By the way, the meetings are a very expensive activity. No wonder that people invent the ways to reduce the length of meetings. You simply need to provide a model with active status such as «In progress» or «In testing». Similarly, in order to understand the progress of the task or the whole version you don’t need the meetings, you should to introduce the practice of tasks estimation, estimation correction in JIRA and promtly work log. The meetings definitely are needed, but in my opinion, they are effective when you need to plan, analyze the risks, or look for solutions, etc.

2. The manager can address to the testing process to understand in which modules, components or areas the most of the problems appear to evoluate problem areas. If you have the team that includes the only one tester for you will be enough to “have a talk”, but if you have big team you can’t collect such information quickly. You need to look through all the bugs and devide them into categories. But it is possible to provide it at once. Those. to think in advance a list of possible categories and select one of them during creation a bug. After that, the following statistics can be obtained very quickly, and you can even monitor the dynamics of changes.

3. The manager has to understand how the project is already differs from the original agreements with the customer. Or actually understand what labor costs are spent on the implementation of the requirements that were not in the technical tasks. By the way, as a rule the conflicts occur with customers at this junction. Analysts will face difficulties if you create a requirements without corresponding characteristics or do not conduct the requirements tracing matrix. As a result, they need to review all requirements and compared with technical tasks.

4. Technical writers will not have to analyze among the hundreds of tasks that are included in the version those that affected to UI changing, if the developers during the task closing will set a special feature that signals about the UI changing.

There are many other examples.

Summing up, I want to say that the “effective model” is more than just the definition of request types and types of relationships between them. First of all effective model is a framework, which defines the “game changers” and the ristrictions which, in combination with the project practices allow to keep order on the project and help to achieve set goals.

Also, you shouldn’t forget that the management of IT-projects is not only a process control. First of all, it’s people management (in fact 90% of the manager time consists of communication with the team).

The use one of a model is not a panacea. No matter how effective the model usage doesn’t guarantee the successful completion of the project.