Set the Stage for Swarming

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:
Sprint Plan with Hours Only

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:

Sprint Plan with Tasks and Test Points

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.

Purposeful Personas and User Stories

The team was pumped to start work on the new Inventory SAAS product and eagerly anticipated the first user story writing workshop.  Bert, the product owner, had been doing a lot of up front work to make sure things got off to a strong start. The team was giddy and the room abuzz.

“Okay team, here are first stories that we should cover,” Bert announced as he displayed his list on the large monitor.

  • Inventory Quantity Forecast data column display on Item Details page
  • Customer Display page using name and address from mainframe CUST_DATA file
  • Web service calls to Forecasting system

The developers just looked at each other.

Aaron, one of the more senior developers, asked, “What is the big picture here?  What are we trying to accomplish with this system?”

“Oh, we are going to build a great new product.  I know what we need to do to beat the competition and how all of the pieces fit together so don’t worry about that.  I need for you to get this built as quickly as possible so I have been working hard to be as specific as possible with how the application should work and how it should look,” Bert explained.

Aaron asks, “Can you at least help us understand who the users are?”

Bert shakes his head.  “Don’t worry about that.  I know our users and I defined four security levels with corresponding page and data access rights.”  He displays the security levels on the monitor:

  • Guest
  • Basic User
  • Advanced User
  • Administrator

The team could start building the system with these security levels and these types of stories.  Bert could provide the exact details to the team and they could build according to those specifics.  But what would Bert and ultimately his customers be losing in working with his team this way?

A customer walks into a hardware store and asks for a drill.  Does he need a drill, or does he really need a hole in something?

On the surface, Bert is taking away the need for the team to think about what they are creating and whose jobs or lives they might improve. The team will not feel compelled to ask if there is a better way to accomplish Bert’s goals or if the product will be a good fit for the different types of proposed users. The team members will not have a sense of who they are truly working for. What if Bert instead had presented the following list of users/personas:

  • Inventory Clerk (high school graduate with basic computer skills)
  • Outside Sales Representative (moderate computer skills)
  • Branch Accountant (CPA – an advanced user)
  • IT Support (site administrator)

Now the team is in a position to better relate to the user base. Aaron asks, “Will the Outside Sales Reps need to access the application via a tablet?”

“Yes, of course.  The user interface needs to support the most popular mobile browsers in addition to the top desktop browsers,” Bert replies.

What about the user stories as originally presented? This product owner is setting the stage for his team to fall into a grind where sprint after sprint they are handed a set of stories to work on without understanding the larger purpose and meaning behind the stories.

What if the “Inventory Quantity Forecast data column display on Item Details page” had instead been written as, “Provide inventory forecast”?  This could set the stage for the product owner and team to brainstorm ways to make this information accessible  throughout the product in ways that could put them ahead of the competition. In the course of this discussion, the developers would gain a sense of purpose and commitment from their involvement in the approach and from realizing the significance of their work.

Creating this sense of purpose is one the product owner’s key motivational tools and cuts to the very core of what makes knowledge workers tick.  Product owners who do this effectively have energized teams that delight them and their customers with every sprint.

Reflections:

  • Craft a goal statement for each sprint – not just a list of stories
  • Write stories that describe the “what” not the “how”
  • Define user roles and personas, not just system security levels