I once started a debate on how to write a User Story.
The most popular style by far is “As a <role>, I want <functionality> in order to <achieve a certain value>.” I am not a big fan of this style because I find most teams either write poor value statements or don’t write them at all. There is power in understanding the value and agile teams are missing this when the user stories are short changed.
I find it’s easier to write a user story when we start with value: “In order to <achieve some value>, as a <role> I want <something>.” A part of Feature Injection, this puts more importance on the value portion of the story. This means we talk about the good stuff more and it even helps reduce scope creep.
The problem I had with the debate was not the answers though. The problem was when other survey respondents said, “I just do whatever I think will work best.” Argh!
Losing Mastery
Our best chance for success comes from knowing how to use our tools. My problem with picking “any old style” is its result: failing to spend time mastering any style. We--in this country and around the world--are constantly jumping to the next big thing. Unfortunately, the deck is stacked against us because the rate of change is accelerating. Technology and our professions are running at an ever-faster pace. Fast enough that we’re losing even the chance to focus.
No masters. Skills, entire professions, especially in tech, now run a 100-year life cycle in a decade or less. No one gains the wisdom of years.
~ John McWade, The Vanishing Master
The nature of learning and mastery is the need to take time and practice. You cannot get good at something without making the effort to practice over time, deliberately trying to get better.
For example, I used to interview a lot of candidates who had not practiced. They often had a title like “Senior Analyst” or “DBA III.” These candidates didn’t qualify as senior on my hiring scale. They had learned enough to perform the basics of their job and stayed in the position long enough to be promoted. Yet without practice, the years spent in the role had not translated into growth or expertise, just time.
Time spent practicing, however, can lead to big changes. Watch the beginning of the TED Talk by Benjamin Zander. He starts with visual and auditory demonstration of how practice leads to huge impacts over the course of a few years.
Gaining Mastery
I was recently coaching a very process bound client. Multiple times a week I would get asked, "What's the best practice for this?" I try to tell them, "It depends," but they don't hear this message very well. They are still beginners and they recognize this. They want one path to follow because the freedom of Agile is troubling. This isn't a bad thing, it just is. In fact, I think their self-awareness of wanting a "best way" is probably a good thing. They are deep in a learning phase and it makes sense they study and practice one thing until they get it right.
Supporting me, is the Shu Ha Ri model. Here's how Gojko Adzic described it in Bridging the Communication Gap:
Shu-ha-ri is a learning model associated with Aikido. It roughly translates to "obey-detach-leave." At the first level (Shu - "obey"), a student learns by closely following one model. At the second level (Ha - "detach"), the student learns that there are multiple models and solutions. At the third level (Ri - "leave"), the student goes beyond following models.
Forced Constraints
As I read about people who are really good at their craft, I read about how current masters are rediscovering the joy of going back to Shu - "obey." It's striking to me how often I read an article about how people who are excelling are discovering their creativity shines brighter when they find themselves stuck within constraints. They achieve more within the restrictions than they were able to outside of them!
My Conclusion
I am afraid we are reaching outside of the constraints stories give us before we have really mastered them. I've been doing this for a couple years and I still struggle with "As a . . . I want . . . In order to . . . ." I find it easier to write when I follow the Feature Injection model of "In order to . . . ." My point is, I don't think I'm a master of either one yet. I need more practice.
My fear is we are taking the easy way out. Reaching for the next thing or what's easiest. Missing the journey leading us to be masters of our craft. Maybe it's just in my head, but I know too many Business Analysts and Product owners who focus on writing quickly to get it done, not thinking about what's right.
I think my colleague Melissa Doerken has the right take, that regardless of which format you use, we must be mindful throughout the writing journey to assure we produce and deliver value, and with reason.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.