Moving Task Cards in the Kanban After Requirements Change in Sprints

Background

This section describes how to move task cards in the Kanban in normal cases and after requirements change in sprints.

Moving Task Cards in Normal Cases

One of the main purposes of using the Kanban is to control the number of WIPs. Pull movement is required to effectively control the number of WIPs and prevent overstock of work items.

Note that a set of moving rules should be customized before the move. The rules are adjusted to satisfy the team.

Moving Task Cards After Requirements Change

• Rejecting the change

  To keep the team going all out for the sprint goal after the sprint backlog and goal are confirmed, requirement changes proposed by the PO are generally not accepted. The PO is responsible for sorting out the sprint backlog. To be specific, the PO should prepare the product backlogs for the next one to three sprints and then develop the sprint backlog based on priority. Therefore, it is recommended that the team reject frequent requirement changes. Requirement rejection also strengthens the PO's control over requirements. Therefore, it is better for the team to move cards in the Kanban normally in this case.

• Embracing the change

  It is unrealistic to completely reject requirement changes. Sometimes, high-priority requirements are subject to changes. For example, if time-sensitive requirements cannot be completed in this sprint, we will fail to get in on the ground floor. However, we must comply with the "NO CHANGE" principle. That is, after receiving a requirement change, analyze the requirement and the impact on the current sprint instead of directly accepting or rejecting the change. In this case, check the following items:

  • Requirements with no value

    Reject the requirements with no value and do not move cards on the Kanban after negotiating with the PO. Here we will spare you the details about where these requirements come from.

  • Requirements with few changes and little impact

    Accept the change of high-priority requirements with little impact on the sprint, but evaluate workload and perform an exchange. To put it simply, replace low-priority requirements that have not been implemented from the Kanban and move them to the product backlog. This is a process of product backlog refinement. Then, add cards of high-priority requirements to the Kanban. When replacing requirements that have been partially done, move them back to the Product Backlog column if we seek to meet feature requirements, or move them to the Done column if the team needs to collect statistics on the workloads on the physical Kanban. In the second situation, if the electronic Kanban also works, move the requirements to the Product Backlog column.

  • Requirements with many changes and great impact

    For changes in high-priority requirements that have great impact on the sprint, stop the current sprint and plan a new sprint. For example, if the requirement in the current sprint is of no value or the changed requirement requires a large amount of workload, you should stop the sprint. Then arrange the card on the Kanban based on the latest sprint backlog.