Planning with pleasure. How we set up processes without managers


    A small company or large-scale enterprise - the process of interaction with the customer is built up everywhere. Somewhere this makes a product / project (underline the necessary), somewhere the team is directly involved in communications. I'm from the second camp. In this article I will tell you how our team has built a process of interaction with customers without the involvement of managers. Under the cut a plan of action, how to organically live with a large number of customers, without burning deadlines and not forgetting about your Wishlist.


    The team in which I work develops a public API and is one of the main data providers for and commercial partners. Any search query with goes through our team - we generate data in response.


    The task set that comes to the team can be conditionally represented as follows:

    • Must-have tasks , on the integrated implementation of which the whole department or company works. They can not be done.
    • Tasks for product support. If something breaks, there must be time to fix it.
    • Techdolg. The presence of these tasks depends on the need and number of others. Unfortunately, in the fight of priorities, they are the first candidates for elimination.
    • Tasks from customers. Those tasks that are not included in the plans of the department, but will do good to one specific customer.

    The first and last types of tasks come from the same people, the key difference is in the priorities and scope of these tasks. If you have to sacrifice something, then most often it will be technical debt and tasks from customers.

    Example: the must-have task is to enable , the task from the customer is to add a new field in the application response.

    The distribution of tasks was almost always approximately the same as described above, but the approach to working with the flow of these tasks used to be different from the current one.

    As it was before

    We were a team that stopped in the middle of the transition from scram to kanban. Trying to control the flow of tasks using kanban boards, we did not abandon the monthly set of tasks that we planned to do in a month - that is, we gathered a typical sprint.

    Collected the entire list of tasks, set priorities and assessments in Google. This required a lot of energy, nerves and time - therefore, the role of the “master plan” was transferred to us, transmitted within the team. A person with this role, in addition to his main tasks, once a month checked the correctness of the formulas for calculating resources, collected must-have tasks, wishes from customers and team wishes. He also held long team meetings to assess these tasks and tried to tamp them into a single list of works, based on their own ideas about priorities. The approach was far from ideal.


    Problem 1. Customers are not clear what is happening with their tasks.

    Every month we asked customers the question “What will happen if we don’t do this task?”. If the non-fulfillment of tasks did not entail monetary losses for us, then most often we gave the command resources to those tasks, the result of which will be visible to the end user. As you remember, customers were from 15 to 20, so some tasks lay in backlog for years and waited in the wings.

    Customers did not understand how much time would pass from the moment the task reaches the kanban board. When forming plans, we said that the task will be released within a month. Maybe. If we have time. In addition, the customer was not clear what to do, with whom to talk and how to start a task so that she would decide.

    Google was not informative. She was both a task list for the month, and a backlog of tasks that was transferred from sheet to sheet. Tasks were lost and duplicated. It was not clear where to insert the task, how to understand whether they took it in the monthly sprint or not. And in general, googled looked repulsive.


    Problem 2. Kanban board does not reflect reality

    In addition to problems with customers, we had a problem with maintaining the relevance of the task list both on the blackboard and in the backlog. Backlog had tasks from the time of the kings, and new tasks were simply lost. On the board, only tasks with deadlines or with the highest significance for the team passed. All other tasks were accumulated somewhere below, in the depths of the board, repeating backlog and increasing the queue of tasks in todo, without any hope.


    Problem 3. The team is not clear what is happening with the tasks.

    Inside the team there was no clear understanding of where the tasks come from, what will be next and what will happen to those that lie at the bottom of the kanban board. Those who undertook to immerse themselves in the subtleties of the process did not share the joy of planning and tried again never to return to the role of “master plan”. Most were in the dark.


    In general, nothing is clear to anyone, tasks are piling up, customers are angry, the team does not delve into the process, because it is complex, and we need to do something with all this. Of all the problems, we derived a list of steps that solved two tasks - to make the client transparent and to make the team transparently.

    Make the customer transparent

    1. Abandoned tamping tasks of all types in one large and complex sprint. As before, every few months a set of large tasks for the entire department takes place, after which the tasks for the near term are clear. In the past, we tried hard to break and pack them by months, promising the release of all tasks by the end of the month. Failure to perform any tasks caused the customer misunderstanding when they were released. Now we give an estimate of how many of them will go down in a few months, and roughly divide by months. In this case, we give the customer a more vague estimate of the timing - for example, it will be done in February or in March - but the customers are satisfied with such agreements. This gave them an understanding of what we would do without giving false promises and without overloading the sprint.
    2. Gone from the prioritization in Google to the prioritization in jira. The practice has spread to technical debt, tasks from customers and tasks to support the product. With this we solved the problem of the complexity of the tool.
    3. Refused to prioritize not must-have tasks from customers. “If you can’t determine the priority, put this task on the tool,” we thought and came up with the customer carousel tool.


      The algorithm of the carousel is as follows: once a week we, in addition to the main set of must-have tasks, take another task from the customer. From whom it is determined by the table, the same as in the example below. And since the order is circular, hence the name of the tool.

      Priorities among their tasks are set by the customer himself, choosing from our backlog, but personally marked for him. In order to work with backlog was comfortable for both customers and for us, we did the following:

      • Archived all backlog tasks older than a year. It was very nice, considering how old the tasks were there. The oldest ticket has been there for more than 4 years.
      • Manually marked all the tasks with a personalized tag of the customer so that you can set up quick filters on the board in jira, within which the customer determines the priority among his tasks. The work is ambitious, but the result was definitely worth it. The customer sees a list of all the tasks he has ever created, changes priorities without notifying the team.


    4. After it became convenient to work with backlog, we returned to the origins of kanban and began again to read and focus on Cycle time tasks - the average time that the task passes through the kanban board. This figure now tells the customer how much time his task will reach release and when he gets on the board. That is, the problem of predictability is solved.

    Make the team transparent

    1. Clean up the blackboard. All unnecessary and irrelevant that lies in the deep todo, closed, and what needs to be done - put in backlog. The kanban board again began to reflect the flow of tasks as it is. Introducing limits to the queue before developing - todo - and to the queue before releasing the release - done - helped to keep the board up to date. To remind the team of the need to monitor the restrictions, they wrote a bot, who writes about this in the team chat when the limits are violated. Here, after killing two birds with one stone, we solved the second and third problems of the past process: the board reflects reality and the team understands what is happening.

    2. Once backlog is a task scheduling tool, you need to keep it up to date. In the light of all the changes, we made a regular meeting, at which we commanded a review of the tasks that came in and ask questions about deadlines and requirements. A big plus of this solution is that the requirements are refined / written before the task hits the board, that is, we carry out simplified analytics in advance, without wasting time during development.

      All tasks that have passed the test team questions, are awarded an additional label that allows them to get on the board.

      The role of the “master plan” has evolved in addition to the role of the duty officer in charge of project support during the week. He needs to throw tasks on the board and hold a weekly meeting.

    No more pain from finding priorities and trying to shove everything at once into a crowded sprint. There are no hours of discussions and clarification of the requirements for a large number of tasks that have arrived in a month - with a weekly analysis, the process is quick, and there are few tasks. Tasks are always in sight and the whole team is in the context of what customers want.

    As it became


    After all the obvious problems were solved, all participants became more transparent, and now you can participate in the process without wasting your time and nerves. Although this is not the final version of the planning process - there is room for improvement everywhere.

    What I want to do next:

    • Automate the process of hitting tasks on the kanban board. Now the tasks come from the backlog by the person on duty, who monitors the presence of tasks on the board for a week. I want some part of the tasks (or, possibly, all their types) to be automatically moved to todo, if necessary.
    • Automate the process of interaction with customers and work with the carousel. A possible solution will be to implement a bot that will remind the next customer to check the correctness of the priorities of their tasks.
    • Automate pulling tasks with deadlines, if any. That is, just add automation to track such tasks.

    Did you solve any of these problems? Share ideas in the comments.

    Want to continue? Join tomorrow's live DevDay Manage IT .

    Also popular now: