In today’s society, many of us are accustomed to scrum and the many benefits we receive when we discipline ourselves with scrum. Part of the strategy that is scrum is developing user stories. At Bridgeport Digital we develop user stories during our weekly sprint. When implemented successfully, our team produces the results we need for the goal we desire. We use the same format when we document our internal processes in an effort to make things easier for ourselves. It also makes it easier to relay that information to others. With that being said, in our format:
We start with an “Operational Definition” which includes:
1. The Purpose
2. How The Process Begins
3. How The Process Ends
4. Intended Functionality
While the user story process begins and ends the same, it is continual. In other words, it happens multiple times in a sprint. In this continual process it provides the context necessary for executing actions items that support the sprint’s goal. The idea is, user stories, groomed to the point of completion, have a transparent understanding from the entire team.
The Purpose: Identify the purpose of each user story; how will it fulfill the needs of the customer?
User stories contain a short explanation, written down and uploaded (to the platform of your choice, at BPD we use Jira) to enforce transparency and accessibility to the entire scrum team. User stories describe a specific set of customer’s needs and how to fulfill those needs with acceptance criteria and metrics. User stories should be easy to understand, use straightforward language, and more importantly, accessibility to the entire scrum team is required for completion. User stories provide a clear image of the customer’s needs and what those needs require. Each piece of work should deliver a particular value back to the customer.
How the process begins: Measure each story to anticipate its capacity.
Each user story has a short written request that is completed in one agile sprint. The scrum team measures intricacies of user stories with story points using the Fibonacci numbers (1, 2, 3, 5, 8, 13). This helps the team accurately estimate how long they anticipate a particular request should take.
Fibonacci Numbers are a series of numbers in which each number is the sum of the two preceding numbers.
1+ 0 = 1 [It takes one day to complete this user story.]
1 + 1 = 2 [It takes two days to complete this user story.]
2 + 1 = 3 [It takes three days to complete this user story.]
3 + 2 = 5 [It takes five days to complete this user story.]
5 + 3 = 8 [It takes eight days to complete this user story.]
8 + 5 = 13 [It takes thirteen days to complete this user story.]
How the process ends: Fully groomed user stories include feedback from customers.
Each story should have connextra format, assumptions, acceptance criteria, scenarios, personas, and metrics (how to measure results). The scrum team must gather feedback by speaking to customers (or potential customers) to establish what they want. Ask for opinions on current products or for suggestions for new features and incorporate feedback into the user story.
The intended functionality: Make user stories public.
User stories are about putting end customers at the center of the conversation. User stories use easy language to provide a context for the team and their efforts. When members on the team read a user story, each member should know why they are creating and maintaining what they’re building and the value it creates.
Put User Stories Into the Product Backlog
Use the product backlog as much as humanly possible because user stories, when broken down, turn into action items using the Fibonacci number system (action items can be completed within a day or two). If your action items can’t be completed within a day or two, they have not been broken down enough. Simply put, it’s about breaking user stories items down using further detail.
The available information is constantly changing. When you first write a user story it won’t be the last time you work on it. As the sprint progresses, the scrum team will gather more information on user stories, which means they’ll need to update the product backlog regularly. Again, this is why we enforce transparency and accessibility because there are times only certain team members are given updated information. Once that info is accessible for everyone (for example, in a platform like Jira), we avoid neglecting the transfer of information which can be detrimental for a team.
When you log all necessary items for creating and maintaining value for the product into the product backlog, the scrum team keeps track of the work necessary for fulfilling a company’s goal. Keep in mind that each process is a different item, ask questions that should be used for user testing and receiving data from customers and rate each story from highest priority to lowest priority (by examining the acceptance criteria).
Now Let’s Take a Moment to Define the Included Scrum Terminology:
Connextra Format
Assumptions
Hypothesis Format
Acceptance Criteria
Scenarios
Personas
Metrics
1. Connextra Format
This format follows the “role-capability-reason” and it was created to describe the three elements; the role, the goal, and the reason (for creating a user story).
a. Connextra Format is as follows; “As a [user], I want [capability], so that [receive benefit].”
2. Assumptions
Assumptions are statements of beliefs used as the foundation for the approach to reach the goals. The team should identify assumptions by asking the question, “what must be true in order to reach the goal?” Then they should form a hypothesis statement to test based on said assumptions.
3. Hypothesis
Hypotheses are statements made with a limited amount of knowledge about a situation that requires validity through testing to confirm the assumption as true or false. This lets the team know whether or not they should continue their investigation for finding the best solution to a given problem. Hypotheses are theoretical decisions we've made about the client and the business. They describe the relationship between our assumptions, anticipated outputs and actions, and the desired outcome. When hypotheses fail, it's usually because one or more of our assumptions are incorrect. As a result, we must alter our anticipated outputs and activities.
Hypothesis format is as follows; GIVEN… (insert assumption here) IF… (insert the action completed) THEN… (insert the anticipated result/goal).
4. Acceptance Criteria
Acceptance criteria are the capabilities and conditions which need to exist in order for everyone to consider the goal achieved successfully. Ask the question, “What characteristics should I be able to observe to know that the Product Goal (sprint goal) has been successfully achieved?” The answer to that question should be documented as acceptance criteria. It is often helpful for PO to consult with their team in order to obtain user experience constraints on acceptable conditions.
5. Scenarios
These are the alternative situations that are observed to be true when trying to reach our target acceptance criteria. It’s possible for circumstances and the information available to change. In an effort to be fully prepared, scenarios show the series of events that ‘could’ happen instead of the intended outcome; what can happen when the acceptance criteria isn’t completed. This gives team members the opportunity to plan ahead of time what they should do, if circumstances were to change, they can act accordingly.
6. Personas
Personas encompass the motives, needs, values, expectations, and goals of a user/customer (depending on the line of work). Personas help the scrum team develop items centered around products and solutions. This is significant when implementing knowledge management in business. Approach the revolving business and users at every point of strategy, implementation, and operations. Personas provide a detailed description of a specific end-user and the product the team is developing for said persona. Personas are written down with a name, profession, and other important details.
6. Metrics
These are crafted beforehand, before testing a hypothesis because of the specific data that the team can track and use to improve efficiency within the sprint. Metrics are best when they are thoroughly defined and then the whole team agrees on implementation. Metrics are insights on how to measure how successful teams are and whether they've attained the goal.
Below is an example of how to write user stories. At Bridgeport Digital, the tool we utilize for our user stories is Jira Align.
Conclusion-Planning With User Stories
The only way user stories can genuinely help the scrum team plan is when they have been implemented the correct way. When developing user stories, if certain aspects are excluded from the process, then it creates impediments and dependencies that delay completing the sprint goal. The scrum master is accountable for eliminating impediments but that doesn’t mean the rest of the scrum team isn’t responsible for vocalizing impediments and offering their own solutions. At BPD, it's from our experience that we say the best way to avoid recurring impediments is to plan thoroughly. This means breaking each user story down with each component listed above (assumptions, hypothesis, acceptance criteria, etc.) because without those components, it’s no longer serving as a tool for the scrum team.