User Story Pairing: focus on priorities

Are your stand-up meetings boring?

Photo by Helena Lopes on Unsplash

Are your stand-up meetings boring? I met a girl recently in a party. She spent her time talking about herself and not listening to what I was saying. Needless to say, that I came back alone, empty-handed that night. The next Monday, I felt the same at my stand-up meeting. All developers were eager to share their progress, and nobody listened or cared about their teammates.

I’m a senior developer / team leader in an Investment Bank in Hong Kong. I lead a small team of 6 developers for a front office desk.

On top of our boring and useless stand-up meetings, there were other issues in our team:

High priority stories were delivered late during the sprint. Sometimes they were even rolled to next sprint.

We lacked transparency within the team. It was difficult to understand why a user story, apparently small, stayed in progress for days: did we under estimate it? Was the story misunderstood? Was it over-engineered? Lack of transparency can lead to lack of trust within the team over time.

And there was significant time spent back and forth between code-reviews and corrections on each of our pull requests.

During one of our retrospectives we decided to change our methodology and try something new. I tested pair programming before, and I had difficulty with it. I strongly believe in the practice, but my eyes are sensitive to brightness change (no kidding). Working on someone else PC, with different luminosity settings, after 4 pm is giving me strong headache.

This time we tried User Story Pairing: 2 or 3 developers working together on one story at a time. Our user stories are small enough for one person to complete it on his own, but also big enough to share the work between 2 or 3 developers.

During the first hours we sit down together, debate and agree on a design. Then we start pair programming on a single PC. We write together the skeleton of the solution: the interfaces, the signature of public methods, the API design, and a few unit tests. Then the group splits the tasks between each other. We all go on our own to implement our own tasks. Rapid and frequent integration is needed but that is not a problem as we share a dedicated feature branch, and we all sit next to each other.

The group is responsible for the story until it is delivered in production. During that period we are allowed to do whatever we think is best to deliver the story. For example, it happens to isolate myself with my peers in a room and do mob programming on a larger screen.

There are never more than 2 or 3 stories in progress at a time. We never start a new story until the current one is done: meaning released in production. We deliver increments of our product almost every day. As we start with the most important stories, we never have to deal with high priority stories rolled to next sprint anymore.

Having less than 2 or 3 stories in progress at a time (for a team of 6) have other benefits. The stand-up meetings are much more focused. With fewer topics to follow, the team is more engaged during the meeting. We don’t even look at our scrum board, as we all know who is doing what.

It also increases transparency within the team and reduces time spent back and forth between pull request reviews and corrections.

Working closely with someone else also favors knowledge sharing. Even as a senior I still have a lot to learn by pairing with colleagues. We share everything, from best practices, to new shortcuts in IntelliJ, business understanding, and source code in our system. It’s quite fun to constantly learn from each other.

It’s been a few sprints now, and the team enjoys it. The momentum is high. We noticed an increase in team delivery, and our stakeholders, including Product Owner, are happier. We went from a team with lack of transparency and boring stand-up meetings, to a team much more engaged, and efficient, with only one simple change: User Story Pairing.

We suffered enough from those people always talking about themselves and never listening. Put a stop to it at your next stand-up meeting.