Redmine's task life cycle for a small development team. Our experience and tips



    I think this article should help people who first decided to automate the task tracking process based on Redmine in the software development group. In the article I will talk about how this process is organized with us, what new fields for the task we have introduced and what problems these fields solve. I think the article will be useful to a wide range of people, in my opinion, setting up the life cycle of tasks is this work under the slogan "Obvious - not obvious."

    Yet! We work in a large corporate environment, mainly for internal customers (and there are several), and this situation is reflected in our life cycle.

    Let's get started.

    It all starts with the fact that at one fine moment a task appears and after its appearance, the task should logically fall on the author. Why?! Because the task should always have an employee who is responsible for its further execution, the one who is currently slowing down the task, the one on whose side is the “ball”, and he must “pass this ball to another”, do something like a football pass . Sometimes this person should not be. For example, when it is no longer necessary to perform actions on a task when it is closed.

    What information do we ask for to fill out the user creating the task?

    Well, of course, this is the type of task, the title and description, but also:

    • “Customer” - that employee who is interested in this task and requested its implementation. He will subsequently check the result of work, and evaluate the performance.
    • “Goal” is the ultimate goal that the task must solve. We did not immediately get to this field. On the one hand, why do we need a goal if there is a detailed description that says what to do ?! But if you think about it, then the goal is completely different. The description of the task indicates what needs to be done to achieve the goal, and if the goal is not fixed, then in the process of completing the task, the goal may be lost, and it will not be completely and not quite as it should be.



    For example, the goal may be:
    "To realize the possibility of calculating the base part of the RFP based on an arbitrary mathematical formula."

    And in the description there will be more detailed key steps and requirements to achieve the goal. For example, “connecting the MathML library, the ability to associate the formula with the calculation period”, etc.

    In general, the description in general may depend on the qualifications of the performer and in some cases it may be just a couple of lines (if you have good communication with the performer, you worked well and understand each other well).

    Where can a new task go?

    Most often, it is sent to the plan, because we often have priority tasks (well, such is the client’s orientation and unwillingness of customers to think about the future).

    But it happens that the task is not a priority and then it can go to the queue (or Backlog, as you like).

    If the task is sent to the plan, then we will definitely ask you to fill in the following fields:

    • “Time estimation” - how much, according to the development manager, this task will take the programmer’s net work time. It is almost never possible to precisely determine this value. But you need to determine approximately. Because this time is actually the price of the issue, i.e. this is not time, this is money for which the customer buys the execution of this task from the development team.
    • Start date and due date. Everything seems to be logical here. Also with us, when a programmer unreasonably squanders a task by the deadlines, then this affects his GP.
    • "Stage" - the same plan or version or sprint in which you plan to complete the task. Our stages coincide with the months. By stages and performers, we control the progress of work.
    • “On whom” - the employee responsible for the execution of the task.



    At the time of setting the plan in the task field “Contractor”, the value from the “On whom” field is always copied. Sooner or later, the task will leave the employee responsible for the execution, but the responsibility for the execution should not go away, therefore, each completed task always retains the executor.

    And if in the queue, then there are fewer fields:
    • “Priority”, so that later, the first to pull more priority tasks out of the queue.
    • “Estimation of time”, so that you can decide what will fit into the future plan and what will not.

    And of course, a task from the queue can always get into the plan, or it can close and get the status of “Closed”. The status “Closed” is fundamentally different from “Completed” in that no tasks were performed on the task.

    What can a performer do with a task?

    Two controversial, but having the right to life functions: “start” and “pause”, which respectively change the status of the task from “Appointed” to “In work” and vice versa. In small groups, this function did not particularly take root, and in some large groups it took root. If there are a lot of programmers and they mark tasks that they are currently executing, then you can build a slice for those tasks that are currently in the work of the performers (a kind of “Work in Progress”).

    In almost any status, an employee on whom at the moment the task can request information from the author, manager, customer, etc. Of course, the performer is no exception.

    Of course, the main function for the executor is the ability to send a task for verification and the button “For verification” of the same name. The button sends the task to the tester, which should be completed by the programmer:

    • The How To Check box is a surprisingly simple and useful thing. I first read about this field in a Scrum book. The programmer, handing over the task for verification, must write to the tester and the final customer what needs to be done in order to take advantage of the new features: which branch from the repository to take, what settings to make, where to go in the interface and what to poke. As a result, a lot of unnecessary questions from the tester, the customer and the team leader go away.
    • Field “What is done”. The programmer does not always do what was originally written in the description of the task. Sometimes it does something extra, sometimes the programmer is given freedom of action in execution. Through this field, the programmer informs the manager, customer and tester what exactly he did as a result of execution. Among other things, we have introduced monetary motivation based on customer assessment of tasks and in this field the programmer can draw additional attention of the customer to the particular tasks that can lead to an increased assessment.
    • The “On whom” field is a tester who will test the task.
    • Checkmark "I posted the task on the test server." Without filling out this field, you cannot send the task for verification. The tester has his own test server for checking tasks, but before releasing the task for verification, the programmer must put it in working order on the test server. First of all, in order for the leader to be able to evaluate the quality of the task execution and he did not have to once again ask to put the task on the test server or do it yourself.



    After sending the task for verification, its status logically changes to "Under verification". Now the tester is responsible for the further execution of the task.

    What can a tester do with a task?

    Well, it’s understandable: send the task for revision (the “Revert back” button) or skip further to the production server (the “Checked” button).

    He can also change the inspector (and the button of the same name), and in our group it is administratively fixed that the tasks must pass the second inspection through the head (in other groups not).

    Why check the head is needed:
    • Firstly, this is the second check, and the second check is rarely unnecessary.
    • Secondly, I am tormented by perfectionism regarding design and usability. And I’m all overdoing it when I see that the interface could be made more harmonious, but the task has already climbed onto the working one.
    • Thirdly, laying out a task on a production server may require notification of a certain group of interested parties, and only the head can make a decision about the need for notification.

    In any case, the transition of the task from the status “To Checks” to the next status “In Operation” is accompanied by filling in a bunch of fields.

    • “Valuation Verification” and “Clarification of Valuation Verification”. Evaluation can put a tester or manager. This assessment allows you to influence the programmer's RFP, including.
    • "Desired date of calculation." When it would be great to lay out a task on a production server (a separate person is responsible for laying out in our group).
    • “Requires alert.” Do you need to notify employees about the availability of new functionality or something else. If required, the tester must do this before laying out.
    • "Presentation". When the task will be presented to customers (this is an interesting procedure, but I will talk about it in another article).



    There is still a bunch of checkmarks for checking before sending the task to the working environment. I will list them, suddenly it will be useful to someone:
    • I checked the absence of recursive and circular SQL queries through RaсkMiniProfiler.
    • I checked the layout on various browser resolutions.
    • I checked the layout and performance in various browsers of the latest versions (Chrome, Firefox, Opera, Intenet Explorer).
    • I checked the plugin's performance on various databases (MS SQL server, MariaDB, PostgreeSQL).
    • I checked the execution of the assignment for compliance with the fundamental rules “Fundamental Rules for Writing Redmine Plugins”.
    • I analyzed the need to notify employees of the holding. Noted the need for alerts in the task.
    • I analyzed the need to update the information in the instructions (if necessary, started a task).
    • The task is posted on the test server.
    • Tasks for writing autotests have been started.

    This is not a simple verification procedure.

    What can a Redmine administrator do with a task?

    He can put it on a working server, thereby transferring the task from the “For Checks” status to the “In Use” status. The task is assigned to the customer.

    What can a customer do with a task?

    The customer may or may not accept the job. If it is not accepted, then he sends the task to the tester for re-examination by writing a comment. If accepted, then presses the button "Completed" and affixes an assessment of implementation and explanation of the assessment. These estimates affect the salary of the contractor and manager.


    In aggregate, we get such a diagram of the task life cycle.



    There are much more transitions between statuses on it than described in the article. For the most part, these are privileged transitions for the manager, when he administratively needs to transfer the task to the next state without waiting for the tester or programmer.

    Of course, this is not all that we have in the task life cycle, but if I wrote about everything, then probably a small book would have turned out.

    I will be glad if you share information about which life cycle is used in your country? What fields do you ask employees to fill out when tracking a task and why?

    Thanks to everyone who read to the end.

    Also popular now: