DevOps as a Service. Part 5. Working with the backlog and end-to-end prioritization of the team

Good morning everyone! Alexander Krylov is with you, and we continue the series of articles about DevOps as a Service, and how using this approach it is possible to solve a number of common problems in organizing the work of a department. In previous articles, we described the approach and showed ways to solve common problems. These materials can be found here Part 1, Part 2, Part 3, Part 4. Today we will discuss the combination of several approaches for managing the team’s end-to-end backlog.

So the problem we will solve is lack of a process for working with the backlog and end-to-end prioritization. It is important to note that the tools that I will mainly use are jira installation server, jira structure plugin, jira kanban. If an implementation is possible in other tools, I will link to them explicitly. But I think that in one form or another, the approach can be reused for other ticket systems.

Let's start with a description of the prerequisites that we need to implement in order for the system to work. First, let me remind you that in Part 2 we implemented the flow for issuetype devops in this form.

Our status model works successfully for requests entering the service and no changes were required. This is good because we have an established process that does not require changes, and regular Daily meetings are held on it with an understanding of what we are doing in the short term – day and week. At daily meetings, every team member, including yours truly, says:

• who did what the previous day;

• what were the achievements or failures;

• what we managed to do and where we need help;

• latest news, if any, on processes and company;

• plans for the next day.

It would seem that everything is standard, but at some point we realized that there are duplications and repetitions, especially when there are voluminous tasks, where looking under a magnifying glass at the volume of tasks per day is more like micromanagement than monitoring everyone’s work. Therefore, it was decided to do meetings 3 times a week.

On Mondays we discuss:

• who has any news, who spent their weekend (up to 4 minutes per person). This is a small team-building element so that all our conversations are not only about work;

• basic plans for the week with the emphasis of the entire unit;

• achievements and failures over the past week;

• latest news from meetings;

• the amount of work of each employee for the week with deadlines and priorities.

And on Wednesdays and Fridays we discuss:

• current tasks;

• difficulties, if any;

• we reconsider priorities with “hot cakes”, if such arrive;

• new problems, if any;

• latest news from meetings;

• other.

“Well, what does the backlog have to do with it, and especially the end-to-end one?” – you ask. To which I will answer: “We need all the pieces of the mosaic so that you understand the whole picture.”

Since there is a flow, meetings for short periods, and there can be 100+ tasks, then we need control tools and time slices over which this control must be carried out. We are expanding our flow kanban with a method that allows us to plan for a longer period, for example, a sprint, which in our case is 3 weeks.

Let me remind you that we have types of work = filters on kanban = epic link in jira, which have their own stakeholders and it looks something like this:

What is superimposed on kanban like this:

Unlike how it is described in Part 2, we have added horizontally placed convenient separating filters by members of our team, which simplifies the work with large volumes of tasks, where filter = types of work, and columns = steps of the previously mentioned flow in issuetype devops. In the settings it looks like this:

Great, there is flow, kanban, daily, there are 3-week sprints. How will we plan them?

Create jira structure –> structure, create structure and choose what is closer to you.

From experience, it is better to do empty or agile.

After this, we switch to automation mode and create folders where each folder will = tasks included in the epic link. Here are 3 options for what can be used as filters to build folder contents:

1. Filter assignment to all team members at the highest level, excluding, for example, all solved tasks, so that only those that are not closed are shown

2. Filter = folder = type of work. In this case troubleshooting

3. Other filters by tags, etc.

After all the necessary settings, we end up with something like this:

For convenience, I will comment on the columns that have been added here:

• Sprint – sprint number;

• Code – task code;

• Subject – task title;

• Executor – task performer;

• Created – task creation date;

• Period of execution – planned task completion date;

• Initial assessment – planned time frame for solving the problem.

Thus, we have a display of all the team’s tasks in one place in the form of a tree structure. That is, we see the entire team backlog with the breakdowns we need.

Of course, this is not all, but here it is worth making a link to an analogue in the form of Notion, which also has the ability to split tasks into projects with a similar set of fields. I’ll show you what this might look like using the example of a project with ProITStand podcasts:

We use it, and we return to jira =)

I reminded you about the devops task type for a reason; you can add custom fields to it, which is what we did. We added a custom field called “DevOps Priority”, which was later renamed “RnDRank”, with the ability to enter only digital values. At the task creation level, this field looks like this:

Great, now we can set end-to-end priorities for tasks. But what method will we use to do this? We will use digital ranges that will be equal to the time frame for taking the task to work.

0 are blockers

1 – 20 are the priorities of the directions epic link

20 – 50 – first priority tasks 1-5 days

51 – 70 – second priority tasks 5-15 days

71 – 100 – third priority tasks 15 – 30 days

101 and above – backlog tasks with low priority, work for the quarter or year.

Based on this, we set our priorities and display the field in our structure for display. How do we do this? We have:

• activity stakeholders;

• allocations per quarter;

• priorities;

• time periods of 3 weeks for a sprint and a quarter for an increment.

These are our time slices when we should clarify the priorities of our tasks. We plan the scope of work for the quarter and prioritize it with stakeholders every 1.5 months, adjusting priorities at meetings if necessary. Within these periods we have iterative meetings where priorities are clarified, for example:

• weekly SOS (Scrum of Scrum);

• weekly team planning on Mondays;

• weekly status of RnD and implementations;

• meetings during the week;

• unscheduled meetings to increase the priority of tasks or when “hot cakes” arrive, etc.

Having understood the priorities and arranging them in our structure according to the previously created custom field, we get a visual backlog with end-to-end priority:

We have added a column RnDRank – this is the end-to-end priority number. In order to manage long-term tasks with a deadline of more than a quarter, we will make an end-to-end priority inside an end-to-end priority so that we can “juggle” them. Why might this be needed? For example, there is a task that is important, but it is waiting for equipment, or there is an understanding that it does not fall into the current sprint or month, but at the same time we do not want to let it out of focus. We put numbers within the range of 70-100, and then operate with a set of labels. First of all, such tasks are assigned the devops_backlog label, and then, depending on the degree of importance, one of the following labels:

Then we monitor such tasks once per sprint, that is, we hold team meetings on backlog tasks once every 3 weeks. For the convenience of monitoring the team’s capacity and how many tasks each fighter can complete in a sprint, a small study was conducted based on Jira filters and a table was born, before presenting which you should enter a term in order to better understand its contents.

Exhalation iteration quantum – a period of time when a team member should be given tasks so that he can breathe out. For example, team member X solves 10-12 problems per week, but 30-36 in a 3-week sprint. Over a long distance, it is physically impossible to maintain such a pace, a person will simply burn out, therefore, once in a certain period of time he needs to take a break from routine tasks and perform proactive ones, or reduce the total volume of tasks for a period of time, for example, a week. That is, if we say that the exhalation iteration quantum is equal to 1 week every 2 sprints, where 2 sprints are 6 weeks, then this could be, for example, every 4 week in 2 sprints. Now let's move on to the table.

But filters are one thing, automated planning. To do this, we began to use time estimation fields in Jira, where when a task appears, the planned time is entered, and then it is correlated with how much was actually entered.

For this we use jira plugin − capacity tracker. We create a template configuration command in it with roles and indicating the work week

We connect tempo teams with our project in jira and our kanban board, if this has not already been done. This is important for end-to-end integration.

It should be noted that here you may have a second board, which will not contain the entire backlog, but only by sprints. It will differ only in the volume of tasks and display only those that will be displayed there based on the custom sprint input field. I highlighted in red the attributes that will differ from the general kanban board.

As a result, we get a general picture with the team’s capacity for a sprint = 8 hours per day, 40 per week and 120 hours per sprint based on time written off in the tempo tracker jira with an indication of who is clearly overworking:

What should we do now with all this beauty?

1. Every week we have clear criteria for changing priorities for sprint tasks

2. Once a sprint, we take part in sprint planning and prioritization of our tasks in it with the formation of team capacity

3. Within the sprint there are clear mechanisms for monitoring the backlog and changing priorities

4. Once every 1.5 months there is a control point for global priorities of increment tasks

5. Monitor the team's workload on a sprint basis.

Thus, using jira plugins and several frameworks for working with the backlog, we got a transparent process for managing the end-to-end backlog of the team’s tasks.

Spoiler – this was the penultimate article from this series, the next one will be the final one, and then there will be a new series or a series of single articles, well, Alexander Krylov was with you, see you again 😉