Operational Planning in Redmine

In the last article I talked about how we set up a life cycle of tasks for programmers in Redmine, now I want to talk about how we plan the tasks in Redmine by month (I’ll probably write about a strategic planning in a separate article).

How do we plan

In brief, I will talk about the operational planning process that works in our IT department.

')

Any employee can write a request to the IT department to develop a function in the software or other work (some applications require the approval of the head, others - not).



The application falls into those. support, which then makes a request for the head of the department responsible for the implementation of this type of work.

The head of the direction, in the event that he sees the need to perform this work, creates a task on the basis of the application and puts it in the plan for a certain month or in the queue (for later), notifying the customer who wrote the application about the shift in deadlines.



Also, the head of the direction sets tasks on the basis of his own vision, filling the plan for the next month with tasks, and distributes tasks among the performers.



On the last Friday of the month, something similar to the Scrum sprint planning takes place (I somehow had this disease methodology). The principal difference is that we have a lot of customers present at the coordination of the plan, and in Scrum on the part of the customer only the Product owner.



The head of the department and key customers come to the planning meeting (key customers are determined by the order and are tied to the direction of development), as well as other customers who are interested in putting their tasks in the discussed plan may arrive at the coordination of plans.



At this small party, it is decided which tasks should be thrown out of the plan drawn up by the head, and which should be included. The manager adjusts the plan and approves the version agreed upon at the meeting.



In the process of executing the plan, urgent orders may arrive to the manager, and he may include them in the current plan based on his own vision.



We came to this process empirically, not immediately, and he lives in the company for a long time.

What we have done in Redmine

Standard Redmine allows you to combine tasks in the version, put down the deadlines and estimated hours. This is probably where the standard planning options end.



Someone may have enough of these opportunities, but we didn’t have enough: there is no possibility to allocate resources, there is no possibility to control the backlog and there is still a lot of things, as it turned out during the implementation process.



In the public domain there are a number of plug-ins for deeper planning. Most of them are sharpened by flexible development methodologies (Scrum, Kanban, etc.). But flexible methodologies are not always suitable for a large company. Moreover, we have different programmer departments with their own specifics, there are a lot of customers and there are no applicants to become a Product owner, it was necessary to implement operational planning and not in the programmer departments.



We used the “Advanced roadmap” plugin for about a quarter, and then we began to make our own and did just that.

Putting in a plan

The first thing we did was introduce the notion of a performer (I talked about this a bit in the last article ). The performer is the one to whom the task is assigned once, and he is responsible for its ultimate performance. The “Assigned” field was immediately renamed to “To whom”; during the execution of the task, this field may change several times from author to customer.



For project managers have made the button "Assign", which puts the task in the plan.





Introduced the concept of the plan itself, which may include several versions. Those. In terms of October, for example, there may be two versions of the program itself. At the same time, in third-party non-programmer departments, for the transparency of work with the plan, an automatic assignment of the task to the plan was made by the completion date. And also, made an automatic creation of the plan and version, if they did not exist. This made planning more transparent for IT professionals.



According to the performer and according to the version (with the possibility of switching in the interface) they began to formulate a plan. The latter, by the way, was renamed to the stage. It was clearer to users.

Prioritization

The problem of prioritization arose rather quickly. The managers had the need to show the performer in what order it is necessary to perform the tasks.



Redmine’s standard text priorities didn’t really fit, because they didn’t set a clear sequence of tasks.



Even in Redmine there is an opportunity to link puzzles in sequential chains. This did not work either, since changing priorities turns into a non-trivial task. The action was sometimes blocked, and the hidden automatic change of terms in the whole chain was not always appropriate.



We recorded the numerical priority in the custom field, and the priority change in the plan was implemented using normal drag and drop, both in the whole plan and for a specific artist. Now, if the situation has changed, then at any time you can reorganize the order of execution. String priorities, however, left to visually reflect the importance of the tasks.

Distribution of tasks

In order to effectively distribute tasks to the performers, we screwed up several counters that showed how complete the plan was for the employee, how much the executor completed it, etc.







If an employee participated in several projects, then it was problematic to calculate his workload according to the project plan, so we made a general plan for the performers, which showed the overall picture for the performers by month. It collected puzzles from all projects, and he gave a more complete picture of the workload of performers.

Approval of the plan

At first, the plan was agreed only in words at the meeting once a month. Over time, customers began to have questions why the agreed tasks left the plan and we screwed the plan approval function into Redmine.



Now, the manager simply clicks the “Agree on Plan” link. After that, a plan is made and you can watch all the changes that are happening to it: how the evaluation of the clock changes, which tasks fly out of the plan, and which ones appear in it, and even how the task headers change. This gives an amazing flexibility to the project manager, and control over the plan remains high.

Where do tasks hang and why

We have both large and small software development departments. In large departments, there is a full set of positions related to software development: analysts, programmers, testers, and a manager. It so happened that analysts wrote the requirements "in the box", but programmers did not have time to write code. It is not very good to control such situations, we came up with an analogue of Scrum-boards (my manager calls it WIP (Work in progress) -deck). Each column of this board can be flexibly configured based on standard Redmine task requests. That is, we can say that the tasks of this query fall into this column, and the requests for this - to another.







The board helps to visualize at what stage of the life cycle tasks are being accumulated.



Sometimes tasks are accumulated not on posts, but on specific people or in specific statuses. Therefore, we made detailed statistics on how much time the tasks were performed in certain statuses and on certain people. These statistics are useful for analyzing the life cycle of tasks, for example, or for estimating the workload of certain people. Statistics is available both within the framework of the entire plan, and within a specific task.







Operational planning has many additional benefits:

• Stop losing work and responsibility.
• The performers had a focus on achieving the plan.
• Control over the work unit has grown.
• There was some kind of mutual understanding between internal customers and programmers. Customers began to see that the IT department is not only an expense. It became easier for performers to explain their workload.

It would be interesting to know what operational planning tools the Habra community uses, and what advantages do they have?