Developers usually want to spend their time doing one main thing: write code. We want to invest our efforts and energy creating, debugging, and (hopefully) testing the software our businesses or open-source teams need. Long hours of non-distracted, focused coding is what most developers want.
So, in agile fashion, lets say you are ready to pick up the next user story in the backlog. You give the description a brief once-over, put on your headphones, start your favorite music, launch your favorite terminal with all your special keybindings to gain that extra productivity edge and git to work (see what I did there? git ...)
15 minutes later, you have to stop to go ask your co-worker to gain clarity about some ambiguous phrase in a user story because you didn’t really read the user story before you picked it up. You just kinda glanced at it and/or looked at the title.
Or even worse, a few days later, you’ve opened your pull-request, all the tests pass, your code is clean and you are on to the next story. Then your reviewer comments “I think you missed a requirement”. Now you’ve been interrupted while working on a new story, which means you have to find a stopping point, put it aside, re-read your old story and re-group your brain to the code you had written.
In both cases, you’ve waisted time. You never really got into flow and you’ve likely interrupted others as well. So much for productivity.
Putting the Cart Before the Horse
Developers tend to — at least in my experience — spend little time reviewing and scrutinizing stories. We leave that up to our product owners or team leads and then give our estimations without everyone agreeing on the requirements. Everyone thinks they understand, but I’ve often found terminology isn’t as universal as we all hope it was: ideas weren’t communicated clearly; everyone has a slightly different interpretation of the requirements; each person thinks about a different way to implement it…
Two days later, we pick up one of those stories, glance at the title, scan the description and get to work in the way I mentioned above. And in the same vain, realize we don’t understand what we need to implement, why we it needs to be implemented in the first place, and find ourselves stuck.
In these situations, we as developers are putting the cart before the horse. We want to just write code, so we put the off the details until later. But, as the saying goes, the devil is in the details.
Review. Groom. Repeat.
Writing user stories and gathering requirements is hard. I don’t think that is new to anybody. In my experience though, the stories with the most consistent estimates and that get implemented the fastest and are the ones that have been reviewed and groomed more than once — though not necessarily estimated more than once.
In our typical story writing flow on our team at Bandwidth.com, we usually have a story written by our product owner, then reviewed by the Team Lead, and then by one or two other team members. Everyone tries to make sure they understand what is being requested, why, and where the best place for the feature architecturally should be. Then its presented to the whole team for estimation.
Its not a perfect process and we skirt it sometimes to be honest. But I can tell you that the times we have stuck to that process and reviewed / groomed a story three or four times before it gets estimated usually moves across the board fastest.
Its not because we made it simpler or took out requirements (though that tends to happen when you groom stories, which is good). The core reason is that everyone on the team was able to have input and gain understanding before ever starting on code.
Every Team is Different
Every team has to understand their unique process though when it comes to story writing. Our team in particular finds ourselves doing more grooming because the flows and patterns that we need to allow for in our application have some rather interesting scenarios and we aren’t feature driven as much as some projects.
Whatever your process is, review and groom stories until your team is ready to estimate it, which is when you can get consensus from the team about what the requirements actually are. I think you will find more consistent estimates, higher productivity when writing code, and a better understanding of the software you are building as a whole.