The story card limits agility

The way people use story cards is wrong. I know it's a bold thing to say, but I think the way most people use story cards is really wrong. There is no doubt about the teams I work and mentor. Don't get me wrong, the story card (storycards) has improved a lot compared to the traditional specification documents we used to use, but I think we can do better. I've been instructing people to create story cards in the traditional way for years, but found that story cards are limiting agility.

Story cards are a common tool for tracking requirements in agile development that can come from the industry, from customers, or from product managers. However, the current format of the story card will make us wrong focus, draw wrong conclusions, waste time, waste of opportunity. In fact, as long as we make a clever and important change to the story card, we can overcome these problems and gain the advantage in the market.

About 90% of the teams use the following format to create story cards:

As __ (role) ___

I want __ (function or feature) ___

To facilitate __ (commercial value) ____

When I was in the Seattle Fuel:coffee Company, I talked to a bunch of friends about agile, lean and life issues. We talk about a lot of things, mainly around the role and importance of product managers. We also discussed the Lean Entrepreneurship (Lean startup) movement and how it affected agile development. It was in that conversation that I began to sigh at the fact that most agile methods did not focus on the activities before and after the development and delivery. Yes, in theory agile methods focus on those activities, but in practice there is no coherent action to support it (except DSDM, of course). The product managers simply store the story cards in the customer's value category, that's all. The feedback and modification of the story mainly occurs in the process of demonstrating the product to the product manager.

It's making me look down. A story card is a fake story if it is not created directly by a customer (a real customer), but by a product manager or customer representative. The stories created by product managers are just hypothetical and professional guesses, what they think they want for their customers. Product managers try to understand the psychology of their customers. But they don't really know how the market reacts until they produce a product or service. Therefore, if the use of "as ... I want to ... "This unconditional statement format, then it is easy to create misunderstanding, let us think that the product manager really know what the customer wants, and forget that it is just a hypothesis."

As each feature requires a certain amount of work to be done, some more, some less. If the story is written "as ... I want to ... "This unconditional statement format, we will mistakenly think he is sure it is true." If we finally find out that this assumption is wrong (often), then we may have wasted a lot of work. Even if the current project is not as often as it used to be at the deployment stage (remember Ford's "Edgar" car and Microsoft's Talking pin), it still wastes unnecessary time and effort even if there is a way to test the hypothesis. However, since it has never been said to be an assumption, then no one will question it.

If the project Manager creates a story card, I think it's better to use the following format:

We (or i) think __ (customer) ___

Want __ (features and features) ___

To facilitate __ (commercial value) ____

For verification, we will ___ (hypothesis test) ________

Change the first line to "We think" so you know the story is hypothetical. If you only say "as", you will be mistaken for the fact that it is certainly valuable to the customer. To say "We think" is to remind you that we are just assuming. If a story is really created by a client, and the story is truly what they say as a (customer), then the story card in the traditional format is all right. You can even write your client's name on it. "I'm John, I want ..." It's better. In this way, you not only have a real client, but also someone's real name is associated with this story. When you have questions about your needs during the development process, you can talk to this person.

In this way, we will have two kinds of stories: (1) The real customer story, the format is "as ..." (2) Hypothetical stories to be tested, in the form "we think ...". Be careful about the second type of story because you're not sure of its effectiveness. If the story is large and complex, then the team should seriously consider whether there is a simple way to validate the hypothesis before putting in the effort to develop it.

If you use a physical blackboard or your management software, I strongly recommend that you distinguish between hypothetical stories and real customer stories with different colors or visually significant differences in the cards. This makes it easy to see where energy is invested. are real customer stories? Or is it basically an innovative hypothesis test?

The innovation hypothesis test is not necessarily the actual development of the product or service, but the verification that the customer wants this product or service. This is the core principle of lean entrepreneurship. The question is "can this product be made?" "But" should this product be made? [1] Therefore, we construct the hypothesis test around the concept rather than the product or service. Eric Reis a Groupon example in his book, "The Lean startup." Groupon did not automate at the beginning, no high-performance servers, no high-speed Internet connections, or even a planned purchase platform. After trying to create a viral marketing platform called the "point", the Groupon team built a website offering discount coupons for pizza stores. They send out e-mails manually, and then send the coupons in PDF format after receiving the reply. It's so shabby! No automatic response, no strong email marketing Automated system. Your story can do the same.

"For the purposes of verification, we will ___" to state the steps you have made in conducting the test hypothesis. The advantage of doing this is that it can complete validation before the demo or deployment ends, and conclude that the story is successful or not. If successful, then very good, you guessed right! If you do not succeed, you also have a harvest, you have at least proved that the assumption is wrong, now it is time to try another plan. You've got experience! You know what customers like, dislike, and understand the customer and change-that's what agile is about.

There may also be potential conflicts between stories. In reality, what people want is not necessarily the same. So, there is a contradiction between a truly understandable story card and a story validation (user needs or assumptions). You might have two real clients, they want something different, or your hypothetical story goes against the real customer story. This may be the case in a real innovation effort. How do you do that? This is a matter for the product manager. Henry Ford had a classic quote-if I had asked the customer what they wanted, they would have told me: "A faster horse." If you are creating a truly groundbreaking thing, then the average user can't give you a hint. That's why you have to use hypothetical stories to explore new ideas that customers are not aware of.

One advantage of the agile approach is that it is continuous improvement. I remember it was a great breakthrough for the team when I first proposed adding "for convenience". Adding the phrase "for convenience" helps us focus on the value of our customers when creating stories, and then focus on delivering what is valuable to our customers. A clear distinction between user requirements and hypothesis testing will help the team understand the focus of the story: provide the services that the user needs, or verify the assumptions. This allows the product manager to see what the focus is on. If an organization is to innovate and make a major breakthrough, it will have more hypothetical stories than the customer needs. By using different card formats for hypothetical stories, we can improve on effectiveness and transparency.

See more highlights of this column: http://www.bianceng.cnhttp://www.bianceng.cn/Programming/project/