Releases And Sprints Planning: A Guide to Elevating Scrum Workflows

Nowadays, there are a lot of teams that build their workflow using the Scrum approach and its ceremonies. Sprint planning is one of the significant parts of this process, which allows the team to understand the scope of issues that they will solve during the sprint and evaluate and prioritize them by the value for the client.

Indeed, planning is the foundation of a Scrum-based management framework. It helps arrange a team, set goals clearly and achieve them. To reach success, a preparation for the next sprint or release should go toe to toe with a clear understanding of what is the scope of the project, what is the sequence of issues in a workflow, who is in charge of performing each task, how much effort and time does the team need to do tasks from the scope, and, finally, what will the team do if stakeholders bring new urgent tasks during the sprint or release.

It seems easy to give the answers to these questions, however, a lot of development teams have faced poor planning procedures and their lamentable consequences.

This article is dedicated to the planning version that is accompanied by my personal comments and notes. I believe that this can improve the process and distribute the initiative between all the members, which eventually leads to better outcomes.

Signs of Inadequate Planning

Improper scheduling destroys all team workflows, increases demotivation and burnout among team members and cultivates negligence from both the team and management. Here are points typically associated with poor scheduling:

• Delay by more than 20% in the performance of the task;

• Permanent postponement of the task due to non-fulfilment;

• Implementation of the plan in advance, reassessment of tasks;

• Underload of employees, occasional lack of tasks for reasons such as dependence on other departments or employees, lack of medium-term plans;

• Constant rescheduling of tasks due to unplanned urgent work;

• Lack of time for internal improvements (automation, technical debt, retrospective, etc.);

• Permanent and/or long-term overtime work of the team.

  
  

Although developer teams encounter such problems, in many cases, they don’t try to change the process. There is a common misconception that only the project manager, product owner or other manager can facilitate the planning procedure. I sincerely believe that no matter what role you play in your project, you, just as any other teammate, can use the following approach to get it going and get others involved to rally the team on the path to change.

Further in the article, I would like to propose a planning system to help get it working. But first, let’s look at the principles.

Goals and Principles of The Proposed Planning System

First of all, the goals of the planning system should be clearly described to show some of the benefits that can be obtained by using it, such as:

• Increasing the transparency of the release process and the timing of its delivery to the client, for both business and team members;

• Creation of a release roadmap;

• Including in the release not only tasks important from a business point of view but also technical tasks — technical debt and bugs that allow improving the product and/or cover the requirements of related departments;

• Reducing the involvement of all team members in planning and giving them time to perform more important tasks instead of attending a meeting in the background;

• Increasing awareness and control by leads of technical debt, bugs and technical issues in tasks of their streams;

• Increasing transparency of issue management via Jira.

  
  

Before describing the planning process from my point of view, it is vital to formulate a few principles that underlie this system:

• Each release should include X sprints lasting 2 weeks, where X is the number of sprints that were agreed by team members. For example, in my team, we have 4 sprints in a release;
• For each sprint, you can plan only 70% of team member work time — 30% is reserved for unplanned tasks and other activities;
• The capacity must be calculated for each worker separately. Tasks must be assigned to a responsible person during the planning session;
• Epics, user story or any other unifying entity with a long live cycle (more than 1 sprint) should not have a sprint, but should have a Fix Version;
• Every task in Jira should be a part of an Epic;
• All tasks shall be in Jira, even if it does not relate to the release development activities to log time. This will directly show what team members have done during the sprint and help to get a "good" burn-down chart;
• Only bugs, tasks and test executions can be a part of the sprint. In other words, issue types that could be solved and closed;
• Every task should be estimated before adding to the sprint;
• Jira tickets should still be assigned to the responsible user after resolution;
• For each subgroup (analytics, development, testing), a separate Fix Version of the backlog should be created that contains corresponding issues;
• Next points if the team commits time in Jira:
  • Time spent on Jira tickets should be logged in Jira. It can be done by any member of the team;
  • Tasks are planned with an accuracy of half a day for most situations.

Planning Description

The following approach suggests splitting one long meeting into 4 events: 2 days for independent work of the subteam and 2 days for meetings of leads. The time spent at each stage depends on the number of team members and responsible persons, such as team leaders who take part in the planning sessions. It shortens if leads participate in the life of its streams actively to reveal the necessities of their subordinates in advance and add tasks to the backlog in time.

During these activities, the team plans the working scope for the next release and the first week of the sprint of the next+1 release. To explain the necessity of why we need to schedule tasks for the next+1 release in part, here are several detailed reasons:

• Since different streams have a shift in accordance with the development pipeline, when one group ends their tasks, the other subteam should take them to work. However, the first subgroup should not have gaps due to the lack of tasks to complete, so we have to take this feature into account when planning;

• Because the planning session is done after the end of the previous release, at this stage it is obvious which tasks were not supposed to be completed and taken into consideration in the current release;

• What is more, it allows us to increase intervals between planning sessions, which reduces the time spent by event participants.

  
  

Day 1

Time: ~15-60 min

Schedule activity type: a placeholder in a calendar

On this day (e.g. Monday), subteam participants are assigned placeholders in calendars for their own work on lists of preferable tasks for future planned releases. Of course, this activity can be performed by team leads of each stream on their own or by organizing meetings with stream members to discuss faced or desired issues and evaluate their importance for future product versions from a stream perspective. However, I highly recommend teaching team members to participate in this part of preparation because it can help leaders to recognize the needs of their subordinates and manage task inclusion respectively.

As advice, to simplify creating Epics and tasks in Jira your team or the Jira service team of your company could develop a script to automate this routine process.

Day 2

Time: ~15-60 min

Schedule activity type: a placeholder in a calendar

During this stage, the leads of every subteam validate issues that were created by other subgroups and evaluate labor costs from their teams. Evaluation can be done by using story points or work days. Completing estimation is essential for future milestones because it helps to fill sprints according to the capacity of each teammate. In the case when leads can’t estimate some tasks they should first check the description in the Jira task and specifications from business or system analysts, and second arrange a meeting with the necessary participants to complete this phase.

If your team works with the business team closely, after finishing this estimation session you can establish a meeting with stakeholders to get priority goals and features for the product from a business perspective. It allows your team to assign priority for choosing tasks in releases accurately.

Day 3

Time: ~30-60 min

Schedule activity type: a meeting in a calendar

This phase follows one key purpose, which is allocating all Epics and tasks that were created at previous stages of planning to the two next releases according to their capacity. Note that filling release capacity should be taken into account. The capacity is the total amount of working days, for example, for a 2-week sprint, the capacity will be 10 working days (if a worker doesn’t have vacations, holidays, etc.). As a result, the next releases will have the subsequent percentage of capacity:

• 70% of the total capacity for the Fix Version N or 7 workdays;

• 35% of the capacity of the 1 sprint of the fix version N+1 or 3,5 workdays.

  
  

In addition, if you take into consideration the different types of tasks that your team regularly encounters, you can allocate them to the planned capacity of each team member as well. For instance, 21% – technical tasks, 21% – features for clients, 18% – launching the release and its support, and 10% – bugs.

Day 4

Time: ~30-60 min

Schedule activity type: a meeting in a calendar

This is the final day of the planning procedure that is required to allocate all tasks from Fix Versions to sprints. Firstly, issues from release N should be distributed to all sprints that your team is determined to work on. Likewise, the release N+1 allocates to its first sprint considering capacity.

As a result of the above actions, you will receive:

• The list of tasks included in each Fix Version in Jira which will be released to the clients;

• The list of tasks included in each sprint according to the capacity of team members.

  
  

The next iteration of planning will take place on the 1st week of the N+1 release. Your team will have to plan the N+1 release and plan 1 week of the N+2 release.

Implementation of The Planning Process

Conducting a new procedure often faces counteraction among team participants. Undoubtedly, you, as a promoter of changes, should take this fact into account and interact with the team members to build planning in a smooth and gentle way. The following points might help you to focus on the main phases of implementation and make this process easy:

• Determine with the team the optimal sprint duration and their numbers for a release. I strongly believe that 1 week is not a viable option and it is necessary to look at the average time of a task completion. Generally, a release demands a minimum 1 sprint for 2 weeks;
• Define the capacity of your team in story points or work days;
• Evaluate the amount of unplanned tasks that your team usually receive during a release and determine the percentage of capacity for such tasks, for instance, 30%;
• Divide the team into subteams such as analysis, development, QA teams, and others, and assign a responsible person for each subgroup;
• Create a Fix Version in Jira for a backlog of each subteam;
• Agree with the team on which entities can be included in the Fix Version or the sprint only and which entities – in both of them;
• Create a dashboard with topical tasks in Jira or in another task tracker that are available to each team member;
• Present the concept to the team, discuss nuances of the workflow, and commit agreements in Confluence or Wiki page;
• Start working according to a new approach. Adjust it to the needs of the team and the project. Don't despair, the process will be easier each time.

Building the proper scheduling process is considered to be a difficult task, however, this article can help you look at the problem from a different angle, increase communication between all team members, and show them that it is not only management and stakeholders who decide what the team will do during the sprints, but also the team themselves.