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.
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.
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:
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).
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.