Spotlight on Spira 6.6 - Kanban Work In Progress (WIP) Support Added | Inflectra

Spotlight on Spira 6.6 - Kanban Work In Progress (WIP) Support Added

August 11th, 2020 by inflectra

One of the focus areas in the new release v6.6 of SpiraTeam and SpiraPlan is to improve the support for different agile project management methodologies and approaches. In this article we'll discuss some of the exciting new features that have been added to Spira to better support the popular Kanban agile methodology.

What is the Kanban Methodology?

As described in the methodologies section of our website, lean development practices are based on the lean methodologies that have been used successfully in manufacturing processes. Kanban is a lean software development methodology that focuses on just-in-time delivery of functionality and managing the amount of work in progress (WIP).

When used for software development, Kanban uses the stages in the software development lifecycle (SDLC) to represent the different stages in the manufacturing process. The aim is to control and manage the flow of features (represented by Kanban cards) so that the number of features entering the process matches those being completed.

Kanban is an agile methodology that is not necessarily iterative. Processes like Scrum have short iterations which mimic a project lifecycle on a small scale, having a distinct beginning and end for each iteration. Kanban allows the software be developed in one large development cycle. Despite this, Kanban is an example of an agile methodology because it fulfils all twelve of the principles behind the Agile manifesto, because whilst it is not iterative, it is incremental.

Introducing Work in Progress (WIP) Limits in Spira 6.6

Spira has always had Kanban views in the product planning boards, but until now there has been no way to enforce WIP limits on the number of cards in each status.

Work In Progress (WIP) limits set the maximum number of requirements that the product team can efficiently manage at each stage of their Kanban process. Using WIP limits can be a useful way for teams to manage their work, allowing them to get through their work faster. This is done by focusing only tasks that can be done now (in other words, the work that can in-progress at any one time).

This feature, is an optional way of using the Planning Board. To not use the feature at all, leave the fields in each of the columns in the table blank.

To make use of WIP limits you need to:

  • set the number of resources for each release and sprint. This represents the number of people working on the release. This defaults to 1 when you create a new release, but can be edited at any time.
  • Set a multiplier for releases and/or sprints. This defaults to 1.0. These values apply to all releases/sprints in the product. Think of the multiplier as the number of requirements each team member on the release or sprint can work on at the same time.
  • fill in the values for releases and/or sprints for each status that you want to set limits on. The statuses shown in the table are all of those that you will see on the planning board. Think of the status percentages as the proportion of all the work that the team can manage once it is in that particular status.

You can have completely separate multipliers and percentages for releases and sprints. Think of multiplies

Example WIP Limit

  • Your sprint has 5 people working on it. So, set the Resources of the sprint to 5.
  • The team can handle developing 5 requirements at once. At the same time they can also test 5 requirements at once.
  • So on the WIP limits table, you can get to this result in different ways. Here are two:
    • set "In Progress" and "Developed" statuses to 50%, and the sprint multiplier to 2.0. This means that the QA team, who takes things that are developed and tests, will have a WIP limit of 5 requirements: 5 (sprint resources) x 100% (of that sprint resource) x 1.0 (multiplier). The same applies to requirements in the status of "In Progress".
    • set "In Progress" and "Developed" statuses to 100%, and the sprint multiplier to 1.0. Looking at just the QA team again, they will again have a WIP limit of 5 requirements: 5 (sprint resources) x 100% (of that sprint resource) x 1.0 (multiplier).

Seeing the WIP Limits in the Planning Boards

When you have WIP limits configured in the Planning Options you will see the new WIP X/Y pill shaped badge in the planning board headers when you choose Group by Status:

This new pill shaped badge is displayed on each relevant status, along with the number of requirement cards in that status for that release/sprint.

  • A status with "space" in it - one where the WIP limit has not been exceeded yet - will be shown in green
  • Any status that has exceeded its WIP limit will be shown in red. You can still move cards into this status: the color is there as an indicator only

agile kanban work in progress wip methodologies