Bill Wake has given us the mnemonic INVEST which help us in writing a well-formed User Story.
Working with User Stories may be easy, but writing effective User Stories can be hard.
Top challenges in Writing User Stories:
Story writing workshop is important to understand the User Story in details and who are the users of that particular functionality and what the users do to use the product.
Conduct a Story writing workshop Quarterly.
Three tips for a successful story writing session are:
Here, there is no need to split using visa card or mastercard, as both come under the category of credit cards.
Interfaces: - Split a story across multiple interfaces (mobile OS or browser) or data interfaces.
Example: As a <user >I want to display in Android device.
As a <user > I want to display in IOS device.
As a <user > I want to display in web browser.
So, it can be split into 3 different logical user stories.
Same is the case with the browser also. Split by different browsers example: Chrome, IE, Mozilla etc, because working in all browsers will take time and the efforts would be large.
There are a few scenarios in which there are complex interfaces. A perfect example will be a sign-up form (with the details) but blank UI. It means the functionality is fully working with buttons and links but no color and proper UI/UX image. The UI can be built in subsequent sprints with a different user story. So, separating the UI work with functionality is also a good way to split the user story.
There is a similar case when the user story says- As a <user> import data from a file and note says (Must support: CSV, Excel and XML) Split each supported file format with different user story as-
As a <user> I want to import data from a CSV.
As a <user> I want to import data from an Excel.
As a <user> I want to import data from an XML
Data: - Develop an initial story with a subset of data.
Example: Suppose I need to buy a car.
As a car buyer I want to know what is the best car in the market.
To come up with this decision, we need to investigate many things example consider mileage, cost, big, small, comfort, features etc. as a separate user story.
As a car buyer I want to buy a car with minimum cost.
As a car buyer I want to buy a car with good mileage.
So, a functionality is developed incrementally with different data inputs to buy a car.
Rules: - Relax business rules or technology standards in an initial version of a story.
Sometimes a user story is considered as large because of the different business rules or business standards.
Example: I want to buy something online for my kid’s birthday party, at least 15 items.
But website shows there is a limitation of 2 items per buyer.
Relaxing a rule is sometimes followed by a user story which is a great way to split.
For example, in a project, we develop some functionality (sort the employees with their skill set). This will be a database query and may take quite a few seconds depending on the load. So, there is a performance issue which is very important to consider. Better to split this as a separate user story.
Add the right amount of detail to the user story. Not too much detail not very less…The right balance is required…
But how to find out if the details are in correct proportion or not?
The answer is “Retrospective”. Ask each team member if the detail that was given was enough to complete the user story in one iteration.
JUST ENOUGH AND JUST IN TIME
The reason is that if the information provided by the BA is not sufficient to complete the user story in one iteration, then there will a delay in the project delivery and customer will not be happy. Similarly, if the detail is too much then a lot of work in upfront needs to be done and the project delivery will be on time and with the exact functionality which was decided before the start of the sprint more like a waterfall model
Let us see some examples of user stories which look fine but can be written in a much effective way.
1) As a Product Owner, I want to display my ratings on my webpage.
Issue/Drawbacks- It is not only about “you”. Focus on End users and stakeholders.
Correct: As a trainer, I want to display my ratings on my web page so that the visitor can choose wisely.
2) Design Brochure Layout
Drawbacks: Not independent, No business value.
Correct: As a restaurant owner, I want to design Brochure Layout so that the visitor gets order from it.
“Identification of who what and Why are the key factors”
So, the user story suggested format/template is:
As a <>, I want <> so that <Business value>.
Few more examples:
The user can run the system on windows xp and Linux
Good user story, but still suggested to split into three
(Windows,XP and Linux)
The user can undo up to 50 commands
Good user story
All graphing and charting are done by third party library.
Not a good user story as user will not care how graphing and charting are done.
The system will use log4j to log all the messages
Not a good user story and log4j should not be written as logging mechanism.
The user can export data to XML
Good user story
A user can quickly master the system
Neither quickly and master should be defined.
Needs to be changed
Your email address will not be published. Required fields are marked *