Leave a comment

Is your Scrum team having problems closing user stories? Swarming can be the answer.

New Scrum teams or Scrum teams that have not matured may find themselves completing a good portion of the tasks in a Sprint but as the Sprint comes to a close they find many user stories still open.  The group collectively scratches their heads wondering where things went wrong as the burndown looked pretty good as hours were dropping throughout the Sprint.  Many times this can happen when individuals work on tasks in a variety of user stories that don’t overlap with user stories being worked by other team members.  Members on developing Scrum teams tend to jump to tasks they are most eager to take on without identifying other tasks they need to complete so as not to create blocks on subsequent tasks.  In the end, you have a patchworks of completed tasks but few user stories closed which causes great angst for QA who usually enters late in the game and are expected to complete all QA tasks in a day or two.  Additionally, it leaves little for the delivering team to demo resulting in disappointed stakeholders and Product Owner.  What’s a team to do?

Swarming to the Rescue

“Swarming” requires the team to put a greater emphasis on the completion of user stories than tasks.  When swarming, the Product Owner will only “open” 2 or 3 user stories at a time.  All members on the team will then focus only on the tasks contained within those user stories.  As user stories complete, the Product Owner will open additional user stories.  This technique has a couple important benefits:

1. for newly formed teams, it boosts confidence as they are completing full user stories in relatively short order

2. it encourages better teamwork as they work closely on a limited number of tasks spread out over a couple open user stories

3. it allows QA to be engaged throughout the Sprint as user stories are ready for testing on a pretty regular basis

4. it narrows the focus of the team to 2 or 3 user stories (vs 10 – 15) which can significantly reduce time lost with context switching

5. sets you up nicely for getting more feedback cycles in your Sprint which we’ll talk about more in a future posting

If you do decide to employ the swarming technique, ensure your Product Owner is monitoring open/closed user stories and that open user stories are clearly communicated to the team.  You may also want to use a user story burndown chart that burns down user stories vs hours.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: