Operational plans in Redmine without additional plugins

    After reading some good articles on organizing operational planning using Redmine tools (for example, here ), I decided to share my experience and write about how operational planning is implemented in our company.

    By operational planning, I understand the creation of a prioritized list of tasks for a specific performer for a given time interval. Accordingly, the total estimate of the complexity for all tasks from the list should approximately correspond to the total working time at a given interval.

    Let's define the terminology


    Sprint - the time interval for which the plan is created (the term is taken from Scrum, and its meaning is the same).
    Employee Operational Plan - a list of tasks assigned to a particular sprint performer.

    In developing the concept of operational planning, the ideas and concepts of Scrum were used, although we do not use this methodology.

    First of all, you need to understand - who needs an operational plan and what is the use of it?

    The operational plan allows us to provide employees with work for a short period of time (we use a sprint lasting 1 week), provide it with access to the entire horizon of tasks for this period, which undoubtedly increases the employees' faith in the adequacy, foresight and professionalism of managers. An alternative is to assign tasks to the performers one or two, as they appear and are ready for work. This is convenient for some managers, but the performers do not like it.

    Experience in applying operational plans has shown that their most effective use is in separate cross-design groups (services), such as technical writers, a product core development group, a third technical support line, etc. At the same time, the described concept of operational planning did not take root in project teams, since its main idea - visualization of the load and the list of tasks of the executor - did not interest project managers (they already control the loading of people and task priorities, combining flexible and rigid management methods, so there is an additional limitation in the form of compiling a list of tasks for a week and following it prevents them).

    Prerequisites for the successful implementation of operational plans


    It makes sense to implement operational planning if:
    • A group of performers performs specialized tasks of the same type (as on a conveyor belt). An example - small software improvements at the request of users in the third line of technical support;
    • Tasks are not overtime (may be in the queue for some time);
    • The priority of tasks rarely changes;
    • Super important tasks, which automatically stand at the top of the list and shift the remaining tasks, rarely come;
    • The duration of the tasks usually does not exceed the sprint time (mostly less).

    It turns out that the operational plan is needed for


    • Employees of groups that work with a large number of short-duration tasks, and tasks themselves can come from various sources;
    • Managers like technical directors and department heads who want to know how busy the employees are and whether the priorities of the tasks are chosen correctly.

    Why is it proposed to use Redmine for operational plans, rather than specialized software like MS Projects? Because operational plans are created in many respects for executors, but not for managers. In addition, operational planning in Redmine allows you to work with the most detailed and decomposed tasks. It is difficult to create and, most importantly, maintain the relevance of such a plan in MS Project.

    Technical implementation


    A feature of the proposed organization of operational planning through Redmine is that it is proposed to use only custom fields and standard filtering of tasks, while no additional plug-ins (both paid and free) need to be installed and studied.

    It is necessary:
    1. Include a ticket to complete the task in the plan. those. in a specific sprint. For this, a custom Sprint field of type List with Multiple Values ​​is created. The list of values ​​is the number of weeks, such as "Week 35", because we have weekly sprints (a plurality of choices is needed if the task is performed within several sprints);
    2. Indicate how much time it is supposed to spend during the sprint to complete this task (since the task, for example, can have a labor intensity estimate of 50 hours, and the sprint contains only 40 working hours). To do this, create a custom field, "Estimate the time for the sprint" of the type "Integer" or "Floating Point", depending on how accurately you evaluate the complexity of the tasks;
    3. Determine the sequence of tasks. To do this, create a custom field "Execution Order" of the type "Integer". This field simply puts the number of the task in the queue for execution within the current sprint, i.e. for the first task to perform - 1, for the second - 2, etc. Next, the list is ranked by this field using standard Redmine tools in the task list.

    This is what the coupon with the new fields

    image

    looks like : This is the operational plan in Redmine:

    image

    If you wish, it can be easily uploaded to MS Excel or PDF using Redmine:

    image

    Unfortunately, as they say, "simplicity requires sacrifice." And in this case, this sacrifice is the inconvenience of collecting the history of planning sprint tasks. For example, to answer the question “how much time did you plan for this task in each sprint during the last month?”, You will have to collect this information from messages about changes in the corresponding fields in the history of the coupon change, because the “Estimated time for sprint” and “Running order” fields will be overwritten every week. However, experience has shown that such statistics are rarely required - usually the entire analysis of the implementation of the plan occurs once at the end of the sprint (in retrospect).

    Now the answer to the second question - what is the use of such operational plans?


    • It is calmer and more comfortable for employees to complete tasks when they see the list for some time ahead and know that this list will be changed only as a last resort;
    • It is easier for managers to form such a plan at the beginning of the sprint (for example, once a week) than to distribute each incoming task;
    • It takes 10-15 minutes for each executor to draw up an operational plan for a week, which is incomparably less laborious than updating the plan in the same way in MS Project;
    • The distribution of tasks by specific performers can be delegated to a team leader, indicating to him a general list of tasks;
    • The transparency of work planning is increased: any employee (manager or contractor) can go to Redmine and view the other employee’s operational plan without unnecessary questions and bureaucracy;
    • The overall management culture is increasing: managers and stakeholders are informed that the operational plan can only be adjusted as a last resort with the approval of, for example, the technical director. Therefore, it is necessary to prepare a list of tasks in advance and determine their priorities. I did not have time to plan tasks for the sprint - wait for the next distribution;

    Some “life hack” when working with operational plans (also found out empirically)


    • In connection with the dynamics of the tasks, possible errors in the assessment of the complexity and other unforeseen headaches, it makes sense to schedule tasks not for the entire duration of the sprint, but to leave some time buffer. We have this stock - 8 hours, i.e. we plan 32 hours for a weekly sprint;
    • The primary source of the plan should be a filtered list of tasks in Redmine (as in the second picture). However, to fix the plan immediately after its creation, it is best to unload its snapshot (in MS Excel or PDF format) - similar to the basic MS Project plan. Further, this recorded operational plan can be sent to interested parties, and also be used in retrospect at the end of the sprint;
    • For the convenience of working with the operational plan according to the described concept, it is most convenient to use the types of trackers and transition schemes from my previous article .

    The described concept was developed as temporary until a more advanced operational planning system was introduced in the company. But there is nothing more permanent than temporary - the scheme has been successfully working for more than a year.

    I will be glad to answer your questions and learn your experience in operational planning.

    Also popular now: