This is a guest post by Rachel Kibler.
My team has been working on a new feature for our returning customers for four months. We thought it would be straightforward. We spent time putting together an architecture for it, and in true kanban fashion, we built one little piece at a time.
At some point, we started a “punchlist,” by which we meant a placeholder story with all the leftover work that wasn’t directly related to the stories we had already finished or written. We also put bugs on there that would be difficult to fix in the stories I was testing (e.g., Internet Explorer doesn’t work, because it never works).
We converted the punchlist into stories, and then we worked on those stories … and then we found even more things. Every story seemed to spawn another two stories of things we had not considered or planned for. Most things were found during testing when I would ask the developer, “Does this story include this mechanism?” and the answer invariably would come back as, “No. That needs to be a separate story.”
I was frustrated, and my team was frustrated. We pushed back our planned launch date by a month. Other teams are already using pieces of what we’ve built, but we haven’t been able to put it all together yet.
I started doing my testing with the product owner, the designer and the developer on the story. Instead of uncovering one or two stories for each one, we would uncover four or five things that needed to be dealt with. That went on for a couple weeks, and we felt like we fleshed out a lot of the rest of the feature.
Now, we’re moving faster. We’re not uncovering as much that still needs to be done in the testing, and we’re only adding a story for every two or three tickets. Developers are feeling empowered to combine things that make sense. The testing is better, the stories are getting done, and it finally feels like there’s an end in sight.
I also see this in my testing group. About once a month, all the testers from various teams will get together with one person’s team and do a bug hunt. Sometimes the product teams seem to feel disheartened at the things we uncover, but the team’s tester seems grateful. I can’t speak for the other testers, but I feel like I have more voices talking about things that also irk me, things that I’m sometimes told are “just how they are.” And other times, the testers find things that I had not considered.
We all get caught in our bubbles so easily. On product teams, we can believe that we have it all figured out. With a specific feature on my product team, we revisited the list of stories frequently, and every time, we thought we had things covered with our current list. We were stuck in that frame of reference. But when the testing starts happening, the weaknesses are uncovered, and the frustration surfaces of why we couldn’t find those weaknesses earlier.
Within my product team, we need to do a better job of planning and refining our stories. I believe other teams at my company could benefit from this too, and probably teams all over.
When we get together as testers to do a bug hunt, it can be jarring to hear that people don’t like what we’ve built as a product team, because our focus has been so narrow and, we believe, careful. But having fresh eyes on a feature or product can shift our mindset and get us out of our bubbles.
I’ve debated about this post’s title. It’s meant to be a play on the adage “many hands make light work,” but in actuality, the title should be “more hands make work better,” because collaboration not only is positive but also makes the outcome better.
