The way you do storycards is wrong. I know that is a bold statement but I believe that for the vast majority of people using story cards it is true. It sure is true for the groups I have worked with and for those that I have taught. Don’t get me wrong. Storycards are a giant leap of improvement over the traditional detailed specification documentation that we used to do but I think we can do even better. For years I have taught storycard creation in the traditional way and it has limited the agility of my teams and my clients.
The Storycard is the de-facto tool to keep track of the requests from the business, customers, and/or Product Owner for the product that an agile team is working on. But the current common format for storycards leads us all down a path and can lead to improper focus, improper conclusions, wasted time and wasted opportunity. With a subtle but important change to the way we format storycards we can overcome these issues and leap ahead of the market.
If you are like 90% of the teams in the world you create your storycards with the following format:
As a__(customer)___
I would like __(Feature or function)___
So that __(value)____
A while back I was sitting at FUEL:Coffee in Seattle, with a couple of friends, discussing all things; agile, lean and life. Conversations were traveling over many topics, mostly around the role and importance of the Product Owner. We were also talking about the Lean Startup movement and how that has influenced agile software development. It was at this part of the conversation that I began to lament that most agile approaches paid no attention to the pre- or post- development/delivery activities. Yes, they do in theory but there is no consistent practice that backs that up (of course with the exception of DSDM). Product owners are supposed to have ordered the story cards in the backlog by the value to the customer, and that is about it. Feedback and modifications to stories comes mostly from the product demos done for the product owner.
Then it hit me. Storycards are lies, unless they are directly created BY a customer, an actual customer, not by a product owner/customer proxy. If stories are created by a product owner they are hypotheses, well educated guesses as to what they think the customer wants. Product Owners try to understand the mind of the customer but no one really knows what the market will do with a product or service until it is created. When a story card is created stating an absolute in the form, “as a…I would like…” it is misleading and makes us all believe that the product owner really knows what the customer wants. At the same time it makes us forget that it is just a hypothesis.
Since, every feature takes a certain amount of effort to create, some more and some less. If a story is written as an absolute, like “as a … I would like…” we all start to believe that it is true. If it turns out that our hypothesis is wrong (and many times they are) then we may have done a lot of unnecessary work. Granted, it is much less than in the old days when big deployments could end in big flops (think the Edsel or Clippy the paperclip) but it is still work that might not have needed to be done, if there was another way to test the hypothesis. But since it was never stated as a hypothesis no one ever thought to question it.
If storycards are created by a product owner it would make much more sense to say:
We (or I) believe that __(Customer)___
would like __(Feature or function)___
So that __(Value)____
And to validate this we will ___(hypothesis test)________
By changing the first line to state “we believe,” you will be acknowledging that this story is a hypothesis. If it just says “as a” then the whole team believes that this is a fact and that the customer WILL value it. Stating “We Believe” calls attention to the fact that we are making a hypothesis. Now it may be that a story was created by a real customer and that story really is their statement of “As a (Customer) …” in that case, absolutely leave the story card in the traditional format! Even more put the customer’s name in there. “I am Jane and I would like…” That is even better. Now you not only have a real customer but a real name a person to associate this story with and with whom to validate any questions during the development process.
If you follow this approach you will have 2 types of stories in your backlog 1) those stories written by customers, they are in the “As a ____” or “I am Jane…” format. 2) You will have stories in the backlog that are hypothesizes and need to be tested, the team can spot those easily because they are stated “We Believe …..” great care should be taken when addressing a “We believe” story because you don’t really know that it is true. If the story is of any significant size or complexity, the team should seriously consider if there is an easy way to find out if this hypothesis is true or not without investing a ton of time in development.
If you are using a physical board, or if your management software supports it, I strongly recommend using a different color card or some other highly visible identification to show which cards are hypothesis and which are customer request cards. By having them easily identifiable it will make it easy to see where your effort is being spent; are you doing all customer requests or mostly innovative hypothesis tests?
Innovative hypothesis tests are not necessarily the actual development of a product or service but the validation that the customer wants the product or service. This principle lies at the core of the Lean Startup. The question is not "Can this product be built?" Instead, the questions are "Should this product be built?" [1] So, we build a test around the concept rather than products or services. Eric Reis uses the example of Groupon in his book The Lean Startup in the earliest days of Groupon there was no automation, no fancy servers or high speed connections and the plan wasn’t to be a group discount platform. After failing to create a viral activism platform called “The Point”. The team built a website to offer coupon discounts for a pizza shop. They sent out emails manually and when they received manual replies they emailed a PDF file with the “coupon”. That’s it no auto-responder, no fancy email marketing automation. You can do the same thing with your stories.
Adding “and to validate this we will ___” is where you state your test to test and validate or invalidate the hypothesis. The power here is that it pulls the validation and success of the story beyond the end of the demo or deployment, into the hands of the customer where the hypothesis lives or dies. If it lives, “Good for you!” You guessed right! If it dies, “Good for you!” You proved that this hypothesis is wrong, it is time to pivot and try something different. You have learned! Learned what your customer likes, and doesn’t like and that, in the end, is really what agility is all about, learning about your customer and adjusting, being agile!
There are potential conflicts here as well. Real people don’t all have uniform wants and needs. So, by making storycard writing more true and transparent to the authorship and the validity of it being a request or a hypothesis, you will have stories in your backlog that are contradictory. You may have two REAL customers who want different things, or you may have stories that are hypothesis’ that are contradictory to REAL customer stories. Any truly innovative work is going to run into this. What do you do? This is where the Product Owner takes over. There is a classic comment attributed to Henry Ford, “If I would have asked my customers what they wanted, they would have said, ‘A faster horse.’” If what you are creating is truly breakthrough then the average user won’t have a clue about it. That is precisely why you have hypothesis stories to explore ideas that your customer might not know to ask.
One of the strengths of agile approaches is that they are constantly improving. I remember when we first started adding the statement, “So That,” it was a great breakthrough for teams. Adding “So that” helped drive our focus toward the VALUE the story was creating for our customer. This in-turn kept us constantly focused on delivering value to the customer in all that we were doing. Making a clear distinction between user requests and hypothesis tests will allow your teams to understand the focus of their story: providing a requested service or validating a hypothesis. It will also allow product owners to see where they are focusing their time. If as an organization you are committed to innovation and building the next big breakthrough, then you should see more hypothesis stories on the board than customer requests. By adding the hypothesis story cards we can take the next leap in effectiveness and transparency.
About the Author
Joseph Flahiff is President and CEO of Whitewater Projects, Inc. and author of the forthcoming book “Being Agile in a Waterfall World: A guide for complex organizations.” He is focused on bringing hope to people who work in difficult business contexts; making sense of these seemingly conflicting approaches, methods and cultures.
Joseph has more than over a decade and a half of experience; executing, coaching, consulting and training in traditional and agile delivery across large scale complex enterprise IT organizations as well as smaller boutique agencies. Joseph's provocative, engaging, and energetic courses and keynote presentations are in demand across the USA and in Europe. Joseph is currently serving on the PMI-ACP Content Support team.
