Writing clear and effective software product stories in your favourite issue tracker can help ensure that your team has a clear understanding of the work that needs to be done and can help keep your project on track. Here are some tips for writing clear software product stories:
- Use a clear and concise title: The title of your story should clearly and succinctly describe the work that needs to be done. Your title should typically be a phrasal verb or generally a call to action. For example, “Create a new login page for the website” is a clear and concise title.
- Add a detailed description: The description should provide a clear and detailed explanation of what the story is about and what needs to be done. For example, “The current payment system is causing delays and errors. The new system will be more efficient and user-friendly.”
- Use the “As a, I want, So that” template: This template is a common way to write stories in issue trackers and can help ensure that your stories are clear and complete. For example, “As a user, I want to be able to login to the website, so that I can access my account.”
- Use descriptive labels: Labels like “bug”, “enhancement”, “task” or “story” can help to quickly identify the type of work being done.
- Include acceptance criteria: Acceptance criteria are a set of conditions that must be met in order for a story to be considered “done.” These should be clear and specific, and should help define what the end product should look like. For example, “The login page should have a form for entering a username and password, and should display an error message if the login fails.”
- Be specific about the work that needs to be done: software product stories should be specific about what needs to be done, and should not be overly general or vague. For example, “Improve the website’s performance” is too general and does not provide enough information about what needs to be done.
- Use links and mentions: Use links and mentions feature provided by your issue tracker to connect related issues together, such as mentioning an issue that needs to be completed before this one, or linking to a design document or a mock-up. For example, “@Developer, can you provide an update on the progress of the new payment system?”
Example:
Title: As a user, I want to be able to reset my password in case I forget it, so that I can access my account.
Label: Feature
Description: The current user account login flow does not have an option for password reset. The new system will allow users to be able to reset their passwords and avoid getting locked out of their accounts.
Attachments: Wireframes for new password reset screens
Assignments: Designer – create wireframes for new password reset, Developer – implement new password reset code.
Comment: @Developer, can you provide an update on the progress of the new password reset feature?
Acceptance Criteria:
- A “Forgot Password” link should be visible on the login page.
- When clicked, it should redirect to a new page where the user can enter their email address to request a password reset.
- A password reset link should be sent to the user’s email address.
- When clicked, the link should redirect to a page where the user can enter a new password.
- The new password should be saved and the user should be redirected to the login page.
In this example, the title clearly states the goal of the story, the label indicates that it is a new feature, the description provides more details about the current issue and the goal, the attachments include wireframes for new password reset feature, the assignments indicate who will be responsible for different tasks and the comment is used to ask for an update from the developer.
By following these tips, you can write product stories that are clear, concise, and effective, which can help ensure that your team has a clear understanding of the work that needs to be done and can help keep your project on track.
