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:
From a quick glance at the board a I silently ponder the possibilities and think of a couple of questions I could ask:
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:
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.