Have you ever come across a colleague or a family member who has a knack for making every conversation about them?
Do you have people in your social circle who influence every group decision to their benefit? Of course you do! When describing these people we typically say “You know the whole world revolves around Joe!” Do we really enjoy spending time with these people? Of course we don’t because they are exhausting and frustrating to work with. Well let me tell you something, these people have a lot in common with user stories. The user story has become the center of the Agile world. Everything in Agile seems to revolve around the user story. They have become exhausting and frustrating to work with for many of us. How did we allow this to happen? How did the Agile community get to choose the technique we must use to convey the requirements for a solution? The BABOK details numerous techniques that BA’s can master for the purpose of eliciting business needs, determining “wants” from true “needs” and communicating the actual requirements which must be met. Why is the user story being elevated in importance over all other techniques? I have personal experience in “Agile” organizations who are absolutely obsessed with the user story. I’ve also been fortunate enough to meet many of my BA colleagues at conferences who have the same frustration. Why do we seem to be limiting ourselves or over relying on this one technique?
Mike Cohn of Mountain Goat Software is regularly credited with coming up with the format of a user story. I’m sure we’re all familiar by now with the “As a _____, I want to _____ so that I can _____.” format. By no means do I intend to discredit this format or this technique. It can be valuable in the right situation.
However I view the user story as a singular tool within our BA tool belt. One single tool should not be the center of any development methodology. Unfortunately I’ve come across some development colleagues who are infected with Agile fever. Agile fever causes the temporary loss of common sense and logic and is characterized by an irresistible desire to adhere to an irrationally dogmatic process. Those infected with Agile fever latched onto the user story as the center of their world since it seemed to have lots of potential. It has a simple format and it seems that anyone can write them. With the user story as the center of the universe time consuming business analysis could be eliminated and replaced with simple user stories and conversation! What a eureka moment this must have been in the Agile community. I can imagine the crazy celebrations which must have ensued. As many of us are learning this is not necessarily working out as planned. Some organizations that tried to eliminate BA’s or relied entirely on the conversation generated from user stories learned that Agile fever can have serious consequences to their business.
So what does Agile fever look like and how can you tell if your team may be infected? Let me give you some examples. A developer once explained to me that he understood the requirements and knew exactly what we were doing and why. However he demanded that the requirements be reworded into the typical user story format because our group was “Agile”. Agile fever was infecting him to the point that he could not function unless the user story became the center of his world. Once the requirements were rewritten he instantly calmed down and was able to function once again! If project team members are demanding requirement rework so you can be “Agile” then you’re likely infected. Agile fever can also cause Goldilocks paralysis. If you’re not familiar with Goldilocks it is the story about a little girl who wanders into a home occupied by three bears. While in the house she tries out three chairs exclaiming “This chair is too big! This chair is too small! And this chair is just right!” I must warn you that Goldilocks paralysis is extremely contagious and can infect entire project teams very quickly. It is characterized by project teams that spend significant time arguing over the size of the user story. You’ll hear comments such as “That story is too big! That story is too small! “We need to break these stories down” or “This story doesn’t fit in our sprint”. As a BA if you notice teams arguing over the size of a story and wasting significant time over it then be aware that they are infected with Goldilocks paralysis. It is treatable with an injection of common sense and reason but it may take a while to take effect depending on how high their Agile fever is.
So what do I suggest we do as BA’s to counteract this over reliance on the user story? I propose that we remember that the word “analysis” is in our job title. Therefore we must never forget that great analysis is what our methodology should revolve around not a single technique. Don’t let anyone influence you away from using other techniques. Great BA’s utilize the right tool or the right technique at the right time to uncover the business needs that will drive business value. The user story is one way to convey that information but it does not need to strictly adhere to the standard format. I have successfully used fully dressed use cases (Oh my!) on a project since they happened to be the best way to convey the requirements for that particular project. Don’t be afraid to think differently and convey the requirements in what may seem to be an unconventional way because it doesn’t fit into the Agile prescription. Drawing a picture, creating a wireframe or using some other visual technique will drive conversation much better than a standard user story. Do some stakeholder analysis to make sure all possible stakeholders are being considered. Then go ask those stakeholders to tell you stories related to the problem that must be solved. Trust me you will have richer conversations and uncover information that the traditional user story would not. My fundamental point is that we as BA’s are software professionals that have creative analytical skills that must not be suppressed by an over reliance on any one technique. So wash your hands, clean your keyboards and get enough sleep so you can avoid Agile fever. If the BA becomes infected then the project team is certainly doomed!