Swarming is the essence of agile teamwork. Everyone on the team pitches in to push stories over the finish line. Egos are left at the door and team members sometimes operate outside of their comfort zones so that the team can deliver on its commitments.

Sprint planning sets the table for effective swarming.  Tasks for all types of work are represented in the sprint plan.  For a software development effort, this includes GUI creation, web development, database development, QA, and any other work needed for the sprint. A user story task list with the team’s estimates might look like:

In sprint planning, the team estimates stories and tasks until they fill up their capacity (available hours to work on tasks) for the period of time covered by the sprint.  This is different from velocity, which is based on user story points or ideal days and provides a rough measure of what can be in a sprint as a high-level release planning tool.

During sprint execution, the team determines based on its WIP limits or other factors whether to swarm on a story.  For example, Web developers could help out with the Develop QA test scripts task if needed to get a story done as the end of the sprint approaches.

Teams who are having trouble swarming may be the victims of their own sprint plan.  Some toolsets or teams treat certain types of work differently in the sprint plan.  For example, Microsoft’s Team Foundation Server (TFS) uses the concept of Test Points as a way of estimating the QA testing tasks and provides progress reporting based on burning up these points.   The plan for this story then looks like:

Notice that the QA tasks are no longer in the task list as the developers’ tasks. As a result, the developers create a sprint plan using the development tasks.  They add stories and tasks to the plan until they have filled all of the projected development hours capacity for the sprint. The QA people create a sprint plan based on test points. While developers and QA are working on the same user stories, they have lost their common pool of work to be completed to get the stories to “done”.

Effective swarming is based on the premise that all team members are responsible all of the work to complete the stories.  Creating a second sprint plan for other work on the same sprint creates a barrier that inhibits people from working outside of their pool of tasks.

Common arguments for this approach are:

“QA should not have to provide separate task estimates because test cases completed are a truer measure of progress rather than hours spent on testing.”

This argument might hold water in the purest sense, but does anyone really want to sacrifice team cohesiveness for the sake of generating status reports that are slightly more accurate?

“QA work cannot be accurately estimated because the level of effort depends on how many bugs are in the code.”

The reality is that all work has a certain level of uncertainty and team members use their collective experience to factor that into their time estimates.

If someone insists that QA work is planned separately from the developers’ tasks, I pity the fool who approaches the ScrumMaster mid-sprint and says, “There is more QA work than the QA person can handle. Can we just tell the developers to swarm on the QA work?”During sprint planning, if the developers filled their available sprint capacity with coding tasks, they don’t have capacity to help with testing!

Reflections:

• Maintaining separate plans for different types of work on a story is a barrier to swarming.
• A sprint plan that includes tasks for ALL of the types of work for the stories provides better visibility and whole-team ownership of all tasks.
• All of the tasks should be estimated in hours and counted against the team’s overall capacity.