Time to replace user stories with work stories

Original author: Alan Klement
  • Transfer
Too many assumptions are dangerous.



I already wrote about the problem of user stories before. Then the best solution for me was to discuss the proposed product changes with the team. This worked great when the team worked together and the product was mature; however, now I am busy creating a new product from scratch with a new team. In this case, since we are developing a project from scratch, we face a problem of misunderstanding when it comes to customer motivation, events and expectations. But today, everything has changed. I found a great way to use the GTD philosophy to better define features.

I call them Working Stories.

Where did it come from


This idea was invented by very smart guys from Intercom. Here is what they say:
We highlight each design problem in the work, focusing on the initiating event or situation, and the expected result is as follows:

When _____, I want _____, then I can _____.


For example: When an important new customer signs up, I want to receive a notification, then I can start a conversation with him.

In that post, it was not called Working History, but I will use this very name later. The article doesn’t pay much attention to the concept, so I’ll explain why I like it and why it’s better than Custom Stories.

The Problem of User Stories (for the umpteenth time)


To summarize, the problem with user stories is that there are too many assumptions and no causal relationship. When a task appears in the format of a user story (As [user type], I want to perform [action] so that there is a [result]), then there is no room for the question “why?” - in essence, you are limited to a certain sequence that is out of context .

And here is how I see this format:



Assumptions and discrepancies between the artificial image and the action

The first problem is that we start with an artificial image, which, in turn, is a very bad idea, and then we design actions that, in our opinion, should be put in order to obtain the expected results. The figure shows that the action and the artificial image are not combined.

Let's look further at some existing User Stories:



An example of how to write User Stories

In the table above, does something really change when someone reads a “moderator” or “evaluator”? If something is added, it is an ambiguity for the flow. I and you will interpret in your own way the meaning of the moderator or why they are presented here in this context.

Try the following. Drop the whole first column (called As a / an - “as someone” - approx. Translator) and see if you lose anything. Compare the following statements:

As a moderator, I want to create a new game by entering a name and an optional description

VS

I want to create a new game by entering a name and an optional description The


sky has not fallen to the earth, is it?

Working History: context and causality rule the ball





Working History Format

Updated: 03/03/2015: Based on more usage and feedback, I now use a slightly different explanation. You can read it in these tweets. I will update the article later.

Look at the image above. Now everything is in place!

All the information presented above is quite critical and very informative, since we focus on causation. Each work story should provide as much context as possible and focus on motivation ... and not just at the implementation stage.

Update as of June 4, 2015: After I had worked with Work Stories for some time, I changed Motivation to Motivation and Strength. Look at the article“5 Useful Tips for Writing a Working History,” which is consonant with this material. You can also learn more about strengths in this podcast and in this short article.

Let's rewrite some examples from the above table of user stories in the form of Work Stories and add motivation and context to each of them:

User History:

As a moderator, I want to create a new game by entering a name and an optional description, then I can invite evaluators.

Working History:

When I’m ready for the appraisers to bid for my game, I want to create the game in a format they understand, then they can find my game and understand why they charge a price.

User History:

As an appraiser, I want to see the product we are evaluating, then I will know what I was given for the evaluation.

Working History:

When I find a product that I want to evaluate, I want to look at it, then I can confirm that I am evaluating the right product.

User History:

As a moderator, I want to select a product for evaluation or revaluation, then the team will see the product and be able to evaluate it.

Working History:

When a product has not been evaluated or I was not satisfied with the assessment, I want to be able to restart the evaluation process and let everyone know about it, then the team will know the specific product that needs to be evaluated.

What about multiple roles and events?


* Added 07/28/2014: Since I get a huge feedback on Work Stories and continue to work with them, I found that it is sometimes useful to include Roles, or Characters as part of the item "When _ Condition is met."

Products with multiple roles

Roles / Characters are most useful when the product has multiple roles, for example, an IT product (Administrator, Manager, Member ...) or a market product (Buyer, Seller). The point is only to clarify who we are talking about.

Consider eBay as an example:

When the Buyer has already bid for the product, he worries that he will miss the counter bid, so he wants to immediately receive a notification about a higher bid so that he himself has enough time to evaluate and change his own bid.

Roles with Cause and Effect

Sometimes there are situations when Work Stories immediately affect multiple roles: establishing a scenario of cause and effect.

And again, consider eBay as an example:

When the Seller is not satisfied with the bids that he receives and takes his product from the market, Buyers who have already made bids want to immediately receive a notification that the product has left, and then Buyers will know that they no longer need to follow the product, but instead look for some other similar product.

Using Events instead of Roles

True, sometimes a situation may arise in which an event affects all roles or role groups: for example, the need to receive a password reminder. In this case, there is no sense in a specific role. It would be more important to talk about it in the context of this event, using such general terms as a client or someone else (but not a user):

When a client, while working with a mobile device, forgets the password, he wants to receive it in a way that facilitates password correction from a mobile device, and then they can continue to register and access their news feed.

Why not a user? The latter looks lifeless and ineffectual, and the buyer, on the contrary, reminds us that we have an audience that needs to be served and respected.

Define motivation, but do not determine the stage of implementation.

Work stories are good because they make you think about motivation and context and reduce the role of any added implementation. Often, due to the fact that people are too focused on the parameters “who” and “how”, they absolutely do not grasp the meaning of “why”. When you begin to understand this “why,” your mind will open up to thoughts on new creative and original ways to solve the problem.

Also popular now: