Scrum: How to work on one story at a time

I was nominated as scrum master in a new formed scrum team. We have already done some sprints. In the beginning I tried to make my team to work on one story at a time. But it didn’t work.
My team had difficulties to distribute the tasks in a way that they can work simultaneously on one story. Maybe we are doing something wrong?

For example: we have a story to create a new dialog. We create the following tasks:

Create Model classes
Read model data from database
Connect model classes with view
Implement dialog handling
Save data on close
Test Documentation
Solution Description

Can theses tasks be done by more than one person at a time? The tasks – more or less – build upon each other.
Or do we design the tasks in a wrong way?

Why should all the team work on a single story?

Why not make stories small enough (and independent enough) so that one person (or better, one pair doing pair-programming) can work on a single story. This process also helps better define the requirements and think more both about the problem and the implementation. Estimates may also be become more accurate, but no guaranties here.

While this depends heavily on the size of the user story, in many cases only one developer should be assigned to a story to avoid having your developers step on each others toes. Though larger or very complex stories may require more developers, but it may also be possible to break those stories into many smaller stories that can be individually assigned.

What we generally do is breakdown the stories into dev / infra / analyst subtasks.

Generally anything thats more than a days work is a story.
Once the tasks are broken down, one or max of two developers work on a
story, depending on the no: of tasks at hand. Usually its one.
We log the time spent, and update the remaining estimate at the end
of the day before we leave or before the daily stand up.
Subtasks are created for any new issues that come up while working.
A Story thats more than 2 weeks work is considered as an Epic.
An Epic can be made up of many stories

What you want your team to do is called swarming, but not every backlog item can be swarmed around by the whole team. Common thought is that swarming requires some pre-conditions:

a cross functional, collocated team
a non trivial story
a definition of “done” that implies the involvement of the whole team

When breaking a story into tasks, the team should already be in swarming mode so that the generated tasks are compatible with swarming and can involve the whole team.

But be careful when using swarming too often or with too many people at once, as you might run into an overswarming problem, when some conflicts might appear between team members as they are too many working on the same item.

You might want to read Mike Cohn’s Should a Team Swarm on to One Backlog Item at a Time? or this article I wrote (yesterday) which deals more specifically with bugs : To swarm or not to swarm

A big part of SCRUM is that the team should be making these kinds of decisions. The backlog should have the user stories with hopefully enough information for tasks to be generated.

While it may be possible to coerce a user story into an item that the whole team can work on simultaneously, what’s more important is that the team picks the items to work on, defines the tasks to finish the user story, and uses the daily stand up to see if you are on track with the promised work.

The pain you are feeling in trying to work on just one story at a time needs to be acknowledged by the team and in sprint retrospective potential solutions needs to be brought up. Figure out what you are doing right and what things need to be improved.

Using your example of the difficulty in distributing tasks that can be worked on simultaneously, one possible solution is to take on multiple stories and delievery 3 or 4 items in a sprint. Since the tasks for this user story build on top of each other it will be difficult to distribute the work. So rather than fight that embrace it.

Your tasks, as indicated, seem ‘small’ enough to be distributed, but there is some coupling between tasks such as the one about modeling the data and retrieving it from the database.

What would be possible is to split it up into three main things people can work on concurrently, with some extra work/setup:

Back-end (database, model etc)
Front-end (using mock data)
Tests (setting up expectations, scenario, etc)

Tasks that cannot be split can be done by pairs. And of course, there’s nothing inherently wrong with more than one story being in progress at any one point; just as long as every member of the team knows what the others are doing, and they can help out whenever needed (as in, ‘shared code ownership’).

You should keep your team focused, yes, but at the same time you need to keep everyone busy, and everyone involved.

Also, how big is your team? This is also a factor; it’s pretty hard to have ten people work on one story, and if you can, your story is far, far too big and should be split up (as should your team).

Filed under: softwareengineering - @ 06:52

Thẻ: scrum, task-organization

Thiết kế website giá rẻ

Danh mục

Scrum: How to work on one story at a time