Your story cards are limiting your agility
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:
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?"  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.
Unable to get Hypothesis Test User Stories to Done
You Hypothesis Test stories concern me in that in most situations the team will not be able to complete the verification of the hypothesis during the Sprint. Hence the story will not be done.
Perhaps it is worth changing the wording slightly to say 'And this will be validated in the future by User Story __(verification story)__'. Yes this is now a dependent story which is not great. However I think it will better reflect the real work flow.
Let's Use Your Format and the Classic User Story Format
Great post! I wanted to run my thoughts by you, since I’ve examined lean concepts related to agile. I’ve categorized product development into three progressive phases where you iterate your way to success.
For a new product (or service, for that matter), something like the Lean Canvas (leanstack.com/) is a great place to begin. You iterate over the Lean Canvas while engaging with potential customers. This is the fastest, lowest-cost approach to modeling what you believe will sell, allowing you to discover what the market values and determining how you will make a profit in the process.
You can then move into the next phase, which is building what you suggest – a minimal viable product (MVP) and iterating over that as you continue to learn what customers value enough to pay for. Your story format: We believe… would like… so that… and to validate this… makes perfect sense to apply in this phase, as you need to find ways to test your hypothesis. This is certainly different from what we do with conventional User Stories.
The final step is to build out an actual, production-ready product. As always, this should be done by defining a minimal set of marketable features (MMFs), and I believe that it is appropriate to leverage the classic User Story format in this phase. I say this because we need to communicate the vision for the product with confidence, but we still want to have a conversation with the team on how to best implement the User Story. If we’ve done our homework in the preceding phases, we should have a solid understanding of the personas involved and the high-level capabilities required of the product so that we can transition to the classic User Story format.
Of course, reviewing the completed User Stories with actual customers/users using short cycles allows us to continue to perform validated learning and adapt based on feedback.
Thanks again for a great post, and I look forward to reading your book!
Stories should describe scenarios and be encapsulated by feature sets or epics
Starting with a feature set / epic:
In order to (business value)
As a (person receiving value)
I want (feature set / epic)
Then the stories that comprise the piece(s) of the feature set would be akin to what is outlined in the following blog posts. I favor a gherkin-like syntax as it is easily understood by non-technical stakeholders and if you are integration testing with cucumber translates smoothly for the developers working on the application.
Reference stories for a user facing feature:
Reference stories for API interactions:
These should both be written collaboratively in real time along with wireframing by the designer with the ownership on the stakeholder and the project team guiding them.
Not sure this makes sense
One of the reasons is something you highlighted, sometimes what needs to be "built" has nothing to do with software and is only an artifact, in other words it's disposable and possibly not even a real construct.
Once the user story gets put into a feature pipeline it should have been vetted to add value.
The other reason is best practices (if there is such a thing) typically results in a discovery team operating outside the day to day of the dev team (though they are of course connected) most dev's crave rationale for a feature product but don't necessarily want to get out of the building themselves to do it and don't like the clutter this creates otherwise.
An upstream BML process is how we do it, sometimes this results in items being moved onto the dev board, and it's called out as a BLM item, as well as it's potential life span
It's good for dev's to explicitly understand this so in general I agree with your idea in principle, in practice, at least for us it has been better to run two boards with the upstream board feeding the down stream board.
How we word story cards is not the issue
This is true regardless if they are written by real customers or a customer proxy such as a product owner. Until we can read each others minds we will always be more or less guessing.
We must accept this uncertainty as a fact, i.e. that we're not sure we're building the right thing.
This is why we build something small, deliver, gain feedback, iterate.
Joseph, great post but..
Stories as intended help bound and focus collaboration between what is needed and the best way to address requirements.
Stories plus acceptance criteria, screen mock ups, data models, persona based usage scenarios, frequent feedback loops reflective on are we doing the right things, test cases, etc., drives out ambiguity and helps to get to what the customer really wants or needs.
InfoQ Sep 01, 2015