Differences between stories and user requests [💰↻70%]

in #business6 years ago

When you work as a product manager, you probably have a lot to show for your product. Each of them describes the wonderful experiences your customers want to have when using the product. And like every time, you need these explanations to be clear and influential. All product managers are responsible for finding what customers really want, through user stories. And here is the difficulty of a product manager. There are also times when you are expected to determine the requirements for what you need to develop without offering any why from the user's perspective.

Let's not forget that most of the new functionality added to your product needs to be determined from the user's point of view, this is not always possible or even useful. Sir example at first, consider security features or infrastructure requirements that are not always affordable by the customer.

There is a big difference between user stories and user requests.

User stories focus on experience, what a person uses the product, wants to be able to do. A traditional application focuses on functionality, what product should do. The differences here, are a thin but important list that goes through some questions like: how ?, who? and when?.

User stories should be in one or two sentences and capture who the users are, what they want and why they want it ?! It is a simple structure for determining the characteristics.

Example: As a user, I want to be able to reset my password so I can go back to the system if I forget it.

Requirements tend to be very detailed and take more time to write. These often go into specific (sometimes very technical) details of how the program should work. These details then guide the development team how to build a new feature or functionality.

Example: Users are allowed to reset their password after they have received a password reset email. The email should contain a unique password reset link and the link must expire after two hours.

User stories can only be written by anyone near the software.

The requirements are written by the product manager, product owner, or business analyst. Technical leaders are often involved as well as engineers who will be responsible for working on features or upgrades. User stories are written during the construction of a product. And updating stories (or adding new ones) can happen at any time.

Requirements can also be created at any time. However, it is better to determine what is required from the user's point of view at first, if both the narratives and the definitions of claims are required. Although the objective of a user's story or request changes, the goal is always the same, so is building a product that customers want.

Return from this post will be 70% of the cost of your voice!
The reimburse will go to all engaged steemians, who voted for this post by more than 0.005 SBD (the minimal quantity for transactions). The only exception - paid upvote services, which feels well enough and without our support. (boosters, support projects, bots...)
Look for our posts under the tag #sbdgiveaway
#SBDGiveaway: The percentage indicated in the post title of the sbd rewards will be distributed to the our UpVoters!

Sort:  

This is an interesting idea you are doing. I wonder if you will have a bunch of success with it?

very nice article thanks for share please upvote my blog @momin109

Coin Marketplace

STEEM 0.30
TRX 0.11
JST 0.034
BTC 66499.54
ETH 3203.31
USDT 1.00
SBD 4.14