Introduction
On this page, we will explain the purpose and how-tos of the primary Jira/project cards you will work with: user stories, tasks, and bugs.
Personas
As we get into writing story, task, and bug cards, we will be referring often to “personas”. A vital component of User-Centered Design, personas are fictional yet realistic representations of target user or stakeholder groups.
They can be users or customers of the product, they can be leadership stakeholders or teammates who have certain requirements for a body of work, or they can even be you and your team.
The value of identifying and defining personas is to create understanding and empathy with the user for whom you are delivering the particular work, and to have a focus for the development team align around.
Note: We will not get into the process of generating personas in this article at this time. But in short, creating personas can be either clearly aparent and require little to no research, or they can be developed based on bodies of data gathered from user research efforts.
User Stories
A user story is something that has an unclear, creative solution (a high level of ambiguity). A persona has a need for a particular outcome. They do not necessarily care how that is done, they just want the outcome.
This does not mean we don’t have a general idea of how to solve the problem, but that implementing that solution can be done in different ways. For instance, if we have to build something new, it could be done manually in Python or through an existing script or through a paid service. How it is done matters less than whether it is done, though the solution should be decided amongst the product or project team.
Writing a User Story
A typical user story is constructed in a way that tells you who you are building or solving for (persona), what they are trying to do (functionality), and why they need to do it (benefit).
AS A… type of customer or role (persona) I WANT… to be able to do this thing (functionality) SO THAT… this desired outcome happens (benefit)
An example will be provided below.
Acceptance Criteria
In addition to the story itself, the ambiguity of how to solve the problem requires a way for us to know whether we have satisfied that story or not. That’s where acceptance criteria comes into play.
Acceptance criteria are the conditions that must be true in order for the customer to accept your solution. They are meant to be clarification for the user story– defining the boundaries of the work you’re producing, sometimes calling out possible negative outcomes that would indicate it did not work, and align the development team around the context of the work.
The most common format is the scenario-oriented format of “GIVEN / WHEN / THEN”.
Scenario: The behavior that will be described below GIVEN this beginning state, WHEN this thing happens or when the user does takes this action, THEN this is the outcome
(Notes: There can be more than one condition for each. If so, add AND conditions. You can also have multiple sets of acceptance criteria to work through the scenario.)
Example of a User Story with Acceptance Criteria
AS A Chase Bank account holder I WANT to be able to recover my password SO THAT I can still access my accounts in case I forgot my password
Scenario: The customer has forgotten their password and cannot log in to their account
GIVEN the customer navigates to the login page WHEN they click the “Forgot Password?” link AND enters a valid email address for password recovery THEN the system sends a password reset link to the customer’s email address
GIVEN the customer receives the password reset link in their email WHEN they click through the link THEN the system enables the customer to set a new password
Tasks
Tasks are something we know how to do and what to accomplish. They can still be complex bodies of work, but there is a lower level of ambiguity to tasks than to stories. The path to solving the problem of a task card is fairly black and white, whereas stories can be solved through varied means, so long as the outcome is satisfied.
Regardless of the complexity, tasks should be written with as much context and clarity as possible. Imagine that you are writing it for someone who is going into this work without any background knowledge.
At its core, a task card should explain what the task is, what problem it is intending to solve, and what outcome we should expect so the team can know whether it has been successfully completed or not.
Below are examples of two types of tasks– one relatively simple and straightforward task, and one that has a higher level of complexity.
Simple Task Example:
Task: We need to enable automatic Zoom provisioning in Okta.
Problem(s): Assigning licenses manually through Zoom and then assigning Okta tiles is laborious, takes time, and is vulnerable to human error. When a user needs Zoom access and does not yet have an account provisioned, they could be blocked from doing their work.
Expected Outcome: When a user account is created in Okta and added to the Roivant Employees group, they will automatically be provisioned a license and tile in Okta.
More Ambiguous or Complex Task:
What problem are we trying to solve?
Sterling is generally good at performing background checks, and are usually quick, but their employment verification process is painful for us and for our candidates.
Why?
Sterling has unreasonable demands for the candidate regarding necessary paperwork to validate employment history, including but not limited to 10 years of historical W-2s. They have also disregarded candidate requests to not contact their current employer and refuse to contact other former employers who could validate employment history. Their process also involves unnecessary, manual HR intervention to kick off BGCs and to overrule failed employment history verifications which are only visible by visiting the portal.
What do we want?
We want a vendor that is more flexible with the employer verification process, without losing any of the positives Sterling’s service provides.
We want candidates to be able to work directly with the vendor to get through the BGC process.
We want this vendor’s platform/portal to integrate with Greenhouse.
We want automated workflows to avoid unnecessary HR interactions while maintaining visibility on the process status.
What is next?
There is no hard deadline, but the sooner the better. The desire is to get some vendor candidates vetted without this being a massive search effort. A lighter-weight RFP process like we’re doing with HRIS will work.
Bugs
These are more system-oriented fixes. Something which we know is broken or not working as intended and needs to be remedied.
These cards can be more straight-forward than tasks or stories as they are not necessarily instructing us to build anything net-new, but simply repairing or refactoring something which already exists.
Bug cards should explain what specific behavior is happening and where, how it is being dealt with currently (if applicable), what user or system problem(s) this is causing, and what the desired behavior should be.
If you know explicitly what the issue is and what the resolution needs to be, then great– write it in there! However, if there is an issue and the resolution is still unknown without further investigation and testing, the clarity and specificity of describing the bug and the desired behavior is vital.
Bug Card Example:
Observed behavior: Newly provisioned accounts in Coupa, via Okta automation, do not have all the desired default Notification Settings at the time of creation.
Workaround: A weekly report and manual update of accounts is used to ensure that new accounts are reset to the desired Notification Settings.
Undesired Side-Effect: The lag in time where the account is active, and notifications are set or reset (manually), creates the following issues:
- Notifications for approvals are not sent in the interim between account creation and manual reset.
- Users may turn off Notifications but have them reset to on as part of the workaround.
Desired Behavior: Default Notification Settings are part of the account provisioning step so that there is little to no lag time between the tile in Okta and the settings being accurate.