With a limited capacity and a overwhelming amount of requests for development, it is not always easy to prioritise work and make sure deliveries flow at a constant rate.

This article explains how we helped one development team to handle the development of a new product while maintaining the legacy software used by more than 2500 users and due to be phased out in the near future.

Context

The Development team One Product Owner One Scrum Master Five developers

The situation

The development team handles two projects at the same time:

• “Legacy” is the software used by 2500+ users on a daily basis. This software is quite unstable and the technology used is now outdated. The team receives user feedback that mainly consists of bugs.
• “Phoenix” is the new software that will replace “Legacy” in the short term. The backlog related to “Phoenix” mostly consists of functional and non-functional stories.

The agreed-on capacity is split 70% Phoenix - 30% Legacy.

What could possibly go wrong?

Even though the sprint planning goes fine and the development ratio is respected, critical issues are raised by users of the “Legacy” software. The Product Owner usually includes those issues in the sprint backlog in order to fix them quickly.

However, the tasks that cannot be completed due to the extra workload are not removed from the sprint and the team cannot complete sprints entirely. Those incomplete sprints do not deliver releasable increments for “Phoenix”, which further delays its completion and the phasing out of “Legacy”.

Even though the usage of a KanBan board provides a good overview of the team’s workload it is not always easy to identify where issues arise.

How to solve this issue?

In order to tackle this problem and provide consistent increments for “Phoenix” while still maintaining a decent level of fixes for “Legacy”, we decided to introduce WIP limits and improve the transparency of the work in progress on the board.

What does it mean in practice?

The board has been enriched with swim lanes for each project and one for the urgent tasks that cannot be planned in advance. Several limits have been set:

• General WIP limit : Maximum 5 tasks in progress are allowed at all times across all swim lanes
• Unplanned tasks limit : Maximum 2 extra tasks can be added during the sprint

Task handling based on the WIP limits

The key idea here is to use the WIP limits as an indicator that should not be exceeded without careful consideration. Depending on what WIP limit is exceeded, the team takes specific actions:

• If a sixth task comes in Work In Progress, the development team informs the Product Owner who has to decide what to do next, with the help of the Scrum Master:
  • Either the additional task will wait until a free WIP slot is available before being worked on
  • Or one task is moved back in the flow and the additional task takes the newly-freed WIP slot.
• If a third task comes in the unplanned swim lane, the Scrum Team informs the product owner who decides whether to
  • Include the new task in the current sprint and remove one of the planned tasks or
  • Wait until the next sprint to address the unplanned task as a standard “Legacy” task

What to remember from this?

This strategy to use WIP-limits enables the team to easily identify bottlenecks in the process, highlight work overload and alert the Product Owner. This leads to more consistent increments for “Phoenix” as well as a shorter reaction time for production issues.

This increased transparency also means that the Product Owner is now able to properly assess the impact of any changes in the sprint and provide visibility to the stakeholders who can then decide what to do next based on complete information.

Finally, the team avoids overloads and benefits from better work conditions that improve the morale.