Time to replace user stories with workers
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. It worked great when the team was working out and the product was mature; however, I am now busy creating a new product from scratch with a new team. In this case, since we are developing the project from scratch, we are confronted with 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 GTD philosophy to better define features.
')
I call them Working Stories.
This idea was invented by very smart guys from the company Intercom. Here is what they say:
For example: When an important new customer subscribes, I want to get a notification, then I can start a conversation with him.
In that post, it wasn’t named Working History, but I’ll use this particular title below. The article doesn’t pay much attention to the concept, so I’ll tell you why I like it and why it’s better than User Stories.
To summarize, the problem with user stories is that there are too many assumptions and no causal connection. When a task appears in a user history format (As [user type], I want to perform [action] so that [result] is), then there is no room for the question “why?” - essentially you find yourself limited to a specific sequence, divorced from the context .
And here is how I see this format:
Assumptions and discrepancies between artificial and 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 get the expected results. The figure indicates that the action and the artificial image are not interconnected.
Let's look further at some existing User Stories:
An example of how to write User Stories
Is there something on the table above that changes when someone reads “moderator” or “appraiser”? If anything is added, it is ambiguity for the flow. Me and you will interpret the moderator’s meaning in one’s own way or why they are presented here in this context.
Try the following. Drop the whole first column (under the title As a / an - “as someone” - comment of the 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 did not fall to the ground, did it?
Working History Format
Update 03/03/2015: Based on more usage and feedback, now I use a slightly different explanation. You can read him in these tweets. I will update the article later.
Look at the image above. Now everything is in place!
All the information outlined above is quite critical and very informative, since we focus on causality. Each work story should provide as much context as possible and focus on motivation ... and not just on the implementation stage.
Update as of June 4, 2015: After having worked with Working Histories for some time, I changed Motivation to Motivation and Power. Look at the article "5 useful tips for writing a Working History", which is consistent with this material. You can also learn more about the powers in this podcast and in this short article.
Let's rewrite some examples from the table of user stories above in the form of Work Stories and add motivation and context to each of them:
User Story:
As a moderator, I want to create a new game by entering a name and an optional description, then I can invite appraisers.
Working History:
When I am ready for the appraisers to bid for my game, I want to create a game in a format that is understandable to them, then they will be able to find my game and understand what they charge for.
User Story:
As an appraiser, I want to see a product that we evaluate, then I will know that they gave me an assessment.
Working History:
When I find a product that I want to evaluate, then I want to look at it, then I can confirm that I am evaluating the right product.
User Story:
As a moderator, I want to choose a product for evaluation or revaluation, then the team will see the product and be able to evaluate it.
Working History:
When the product was not evaluated or I was not happy with the assessment I received, I want to be able to restart the assessment process and inform everyone about it, then the team will know the specific product that needs to be assessed.
* Added on 07/28/2014: As I get a huge feedback about Work Stories and continue to work with them, I found it sometimes useful to include Roles, or Characters as part of the “When _ Condition” is met.
Products with multiple roles
Roles / Characters are most useful when a product has multiple roles, for example, an IT product (Administrator, Manager, Participant ...) 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 offered a price for the product, he is worried that he will miss the counter rate, so he wants to immediately receive a notification about the higher rate so that he has enough time to evaluate and change his own rate.
Roles with Cause and Effect
Sometimes there are situations when Work Stories immediately affect multiple roles: setting a scenario of cause and effect.
And again, consider eBay as an example:
When the Seller is not satisfied with the bids he receives and takes his product from the market, Buyers who have already made bids want to immediately receive an alert that the product has dropped out, and then Buyers will know that they no longer need to follow the product , but instead it is worth looking for some other similar product.
Using Events instead of Roles
However, sometimes a situation may arise in which an event affects all roles or groups of roles: for example, the need to receive a password reminder. In this case, there is no point in a particular role. It would be more important to speak about it in the context of this event, using such general terms as customer or someone else (but not the user):
When a client, while working with a mobile device, forgets the password, he wants to get it in a way that makes it easier to fix the password from the mobile device, and then they can continue to register and get access to 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.
Determine the motivation, but do not determine the stage of implementation
Working 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 of "who" and "how", they absolutely do not capture the meaning of "why." When you begin to understand this “why,” your mind will open up for thoughts on new creative and original ways of solving a problem.
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. It worked great when the team was working out and the product was mature; however, I am now busy creating a new product from scratch with a new team. In this case, since we are developing the project from scratch, we are confronted with 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 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 the company Intercom. Here is what they say:
We highlight every 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 subscribes, I want to get a notification, then I can start a conversation with him.
In that post, it wasn’t named Working History, but I’ll use this particular title below. The article doesn’t pay much attention to the concept, so I’ll tell you why I like it and why it’s better than User Stories.
Problem User Stories (for the umpteenth time)
To summarize, the problem with user stories is that there are too many assumptions and no causal connection. When a task appears in a user history format (As [user type], I want to perform [action] so that [result] is), then there is no room for the question “why?” - essentially you find yourself limited to a specific sequence, divorced from the context .
And here is how I see this format:
Assumptions and discrepancies between artificial and 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 get the expected results. The figure indicates that the action and the artificial image are not interconnected.
Let's look further at some existing User Stories:
An example of how to write User Stories
Is there something on the table above that changes when someone reads “moderator” or “appraiser”? If anything is added, it is ambiguity for the flow. Me and you will interpret the moderator’s meaning in one’s own way or why they are presented here in this context.
Try the following. Drop the whole first column (under the title As a / an - “as someone” - comment of the 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 did not fall to the ground, did it?
Working History: context and causality rule the ball
Working History Format
Update 03/03/2015: Based on more usage and feedback, now I use a slightly different explanation. You can read him in these tweets. I will update the article later.
Look at the image above. Now everything is in place!
All the information outlined above is quite critical and very informative, since we focus on causality. Each work story should provide as much context as possible and focus on motivation ... and not just on the implementation stage.
Update as of June 4, 2015: After having worked with Working Histories for some time, I changed Motivation to Motivation and Power. Look at the article "5 useful tips for writing a Working History", which is consistent with this material. You can also learn more about the powers in this podcast and in this short article.
Let's rewrite some examples from the table of user stories above in the form of Work Stories and add motivation and context to each of them:
User Story:
As a moderator, I want to create a new game by entering a name and an optional description, then I can invite appraisers.
Working History:
When I am ready for the appraisers to bid for my game, I want to create a game in a format that is understandable to them, then they will be able to find my game and understand what they charge for.
User Story:
As an appraiser, I want to see a product that we evaluate, then I will know that they gave me an assessment.
Working History:
When I find a product that I want to evaluate, then I want to look at it, then I can confirm that I am evaluating the right product.
User Story:
As a moderator, I want to choose a product for evaluation or revaluation, then the team will see the product and be able to evaluate it.
Working History:
When the product was not evaluated or I was not happy with the assessment I received, I want to be able to restart the assessment process and inform everyone about it, then the team will know the specific product that needs to be assessed.
How about multiple roles and events?
* Added on 07/28/2014: As I get a huge feedback about Work Stories and continue to work with them, I found it sometimes useful to include Roles, or Characters as part of the “When _ Condition” is met.
Products with multiple roles
Roles / Characters are most useful when a product has multiple roles, for example, an IT product (Administrator, Manager, Participant ...) 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 offered a price for the product, he is worried that he will miss the counter rate, so he wants to immediately receive a notification about the higher rate so that he has enough time to evaluate and change his own rate.
Roles with Cause and Effect
Sometimes there are situations when Work Stories immediately affect multiple roles: setting a scenario of cause and effect.
And again, consider eBay as an example:
When the Seller is not satisfied with the bids he receives and takes his product from the market, Buyers who have already made bids want to immediately receive an alert that the product has dropped out, and then Buyers will know that they no longer need to follow the product , but instead it is worth looking for some other similar product.
Using Events instead of Roles
However, sometimes a situation may arise in which an event affects all roles or groups of roles: for example, the need to receive a password reminder. In this case, there is no point in a particular role. It would be more important to speak about it in the context of this event, using such general terms as customer or someone else (but not the user):
When a client, while working with a mobile device, forgets the password, he wants to get it in a way that makes it easier to fix the password from the mobile device, and then they can continue to register and get access to 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.
Determine the motivation, but do not determine the stage of implementation
Working 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 of "who" and "how", they absolutely do not capture the meaning of "why." When you begin to understand this “why,” your mind will open up for thoughts on new creative and original ways of solving a problem.
Source: https://habr.com/ru/post/295900/
All Articles