short link: http://goo.gl/jbyusW
Also Known As:
Motivation: In theory, the most efficient way to work is one item at a time. Critical defect fixes can require this high level of as and when they arise.
Structure: A development team accepts and actions only one backlog item if the associated Quality of Service demands that such prioritization be given. The Work In Progress is limited to one.
Applicability: Swarming should be considered in situations where an urgent requirement demands the attention of the whole development team, and where work on other requirements can be suspended. Note that for Swarming to be viable, it must be possible for multiple developers to work on one item simultaneously and without causing each other impediment.
Consequences: Swarming, when applied in the right situation, can result in a faster response time and a more rapid turnover of defect fixes and small changes. However, it can also lead to waste if developers are allowed to get in each others way.
Implementation: Swarming can be implemented for Lean Kanban teams of small size, where developers will not cause each other impediment by working on the same item. It is rarely implemented in Scrum development teams, since they are expected to work on the delivery of a Sprint Backlog for the achievement of a Sprint Goal, and not to vary the quality of service of individual backlog items.