I want to address a question that I got recently and that comes up every month or two. I was recently emailed the following:
Most of our teams complete 10 or more user stories per sprint. When answering the 3 questions in the daily scrum, it was clear what each person was working on, but it wasn't as clear how each story was doing or when a story was in trouble. For example, if no one worked on a story, problems with that story aren't visible because no one mentions that story during the daily scrum/standup.
What we've started doing is conducting the daily standup story-by-story rather than person-by-person. Now it's very clear how each story is progressing, but difficult to figure out what each person is doing. Some people work on multiple stories and others may not even speak up in the daily scrum.
Solution 1: Reduce number of sprint backlog items
One possible solution to this common problem is that these teams are doing too many product backlog items per sprint.
Based on data I analyzed on successfully finished sprints, I determined that a Scrum team should average around 1 to 1-1/2 user stories (product backlog items of any sort, really) per person per sprint. So, a six-person team should get somewhere around 6-9 user stories done per sprint. Teams doing shorter sprints (one or two weeks) should be at the low end of the range; teams doing three- or four-week sprints should be at the upper end. This means that coincidentally teams with longer sprints do slightly larger user stories in their sprints.
I hate that the answer I got was around one user story per person in a sprint because that makes it sound like each person grabs one user story and works on it alone for the duration of the sprint. Nothing could be further from the truth.
Expressing the number of items in terms of the number of people on the team is just an obvious way to state the result: more people, more user stories. I want to reiterate though that the result is not for each person to do one user story per sprint alone.
Solution 2: Point to stories during the daily scrum
Another solution to the problem above is to conduct the daily scrum in front of a physical task board and have people point to whatever they are working on. I always prefer to do this whenever possible. I frequently ask the speaker to "Point to what you're working on." Assuming a well setup taskboard this will show me the user story that the task relates to.
Solution 3: Designate a point person
Another solution is to designate a "point person" for each user story the team plans to work on in the sprint. This person is responsible for knowing if the user story is moving along appropriately. The person is essentially a "story owner" but we're talking about 2-5 minutes a day of extra work. This isn't a heavyweight new responsibility. The person may or may not be the primary contributor on the story; it doesn't seem to matter.
Solution 4: Reduce team size
Another possible solution could be to look at the sizes of the teams involved, emphasizing agile teamwork by maintaining smaller, more cohesive teams. I find the ideal Scrum team size is 5-7 people. Standard agile advice seems to be 5-9 is the right size. When possible I try to stay on the low end of the range. If the team is more than 9, it is easy to lose track of what people are doing.
Experiments with Daily Scrum Formats
Finally, most teams do the daily scrum per-person, but some encounter the problem described here and discuss things story-by-story. Not all teams need to do it the same.
If you're in an organization with even a handful of teams, I would randomly split them and tell some to try person-by-person and others to try story-by-story for a full sprint. I'd get everyone together afterwards for a short cross-team retrospective and invite people to say how it went.
Hopefully teams could hear the results of other teams and then make a good decision about what to do next.
