In my last post about Introducing Agile Practices to Manage a Remote Development Team I described the issues we faced with our existing development process and provided a step-by-step overview of the agile practices we implemented. In this post, I want to introduce you to the concept of User Stories and how you can use them to streamline your development process and put your users first.
Concentrating on Individual User Values Instead of Complete Feature Sets
One of my main concerns was the mix of topics being simultaneously discussed: Complete new modules and single features as well as typos and minor layout enhancements. To simplify discussions, I asked everyone to break down bigger features into individual user functionalities – User Stories. Instead of trying to fully specify a complete module like Questions & Answers, we started to talk about things like
“As a user I want to be able to ask questions so that I can solve my issues with my car” or “As an expert I want to be notified about new questions regarding my field of expertise so that I’ll be able to help quickly”.
Focusing on User Value Helps Comparing Features With Bug Fixes
Breaking things down into User Stories forced us to highlight the exact features a new module should provide to the users, what was crucial at launch and what could be delayed. Additionally, it allowed us to prioritize these User Stories along with improvements and bug fixes, as we now had common ground: the value provided to the user.
Using a Simple Template Helps to Focus on the User Value
It took some time for the team to get used to this type of thinking. What helped was introducing this simple pattern for formulating User Stories as described by Dan North in his article What’s in a Story and discussed by Mike Cohn in his article about Advantages of the “As a user, I want” user story template
As a …
I want to …
So that …
Using this pattern you get into the habit of defining an actor (As a), the specific functionality (I want to) and, most importantly, the reasons why the feature is relevant for the user (So that). Of course, this pattern is not applicable to development topics like typos, minor cosmetic changes, etc. But, trying to apply this pattern even to bug reports will help in prioritizing bugs against new features later on. I will discuss this process in the next post of this series: A Backlog for ruthless prioritizing.
Agile Web Operations 