Smaller User Stories?


Alice was talking with me the other day about User Stories. She was telling me how we “must really get to smaller stories because our testers on the team are overloaded near the end of the Sprint”. Alice then goes on to remind me that “The team has plenty of resources. (arghhh!) There are six developers and two testers.”.

Alice has come to the conclusion that smaller stories means our testers won’t be overloaded. I would agree that smaller stories might help, but could something else lay at the root of the problem?

I take a short stroll across the room to look at the team’s board. It’s day two of the 10-day Sprint and the board looks like this:

Create a preferred customer

From a quick glance at the board a I silently ponder the possibilities and think of a couple of questions I could ask:

  • Why are so many stories being actively worked on?
  • I see there is a QA column on the board. What does that do for them?
  • It appears that the developers are pretty busy right now. What are the QA folk on the team doing now?
  • There are “only” five stories being worked on, I wonder what the sixth developer is doing?

Let’s explore the first question a bit further. Why are so many stories being actively worked on? A few of the possibilities going through my mind as I look at the board are:

  • Do developers only have the skills to work on certain stories?
  • Does management believe that being able to attribute work to a particular person makes it easier to gather data for “performance” reviews thus we need to track each person’s work?
  • Do team members believe its more efficient for each person to work on their own story and pairing is viewed as inefficient?
  • Does the team know how to collaborate?

Using the 5 Whys approach, each of those above points could easily expand into discovering many additional possibilities.

And that is the point.

Rather than me jumping to a conclusion that overloaded testers at the end of a Sprint means stories must be too big, get the team involved to do some deeper analysis. Involving the people doing the work will certainly draw some perspectives about the problem. The Retrospective is a perfect setting to focus on such a problem. By taking to time to drill down into the possibilities and understand the root causes the team can come up with a small improvement to try.

View the improvement as an experiment. Rather than becoming attached to the outcome of the experiment look at the outcome as “Ahh, interesting” – a learning opportunity that can help to determine the next experiment.


comments powered by Disqus