Advanced User Stories

Transcription

1 Advanced User Stories Reference Materials

2 What is a User Story? THE BASICS User stories are nothing more than a placeholder for conversation. Often referred to as a plain, simple statement of a requirement, using plain English. They are a way for phrasing requirements that forces individuals to better align the requirements to the needs of users. (Where the user is never referred to generically as user.) As a user role, I want desired function, so that the benefit of the function. Bill Wake s INVEST is likely the most popular mnemonic for describing well-written user stories. Independent Negotiable Valuable Estimable Small (or perhaps Sized Appropriately) Testable While the construct of a user story has three primary parts, the 3 parts alone, do not complete the user story. It is necessary for the user story to include Acceptance Criteria, or conditions of satisfaction that describe the characteristics the solution must possess in order to meet the needs of the user or stakeholder. 1. WHO As a user role, 2. WHAT I want desired function, 3. WHY so that the benefit of the function Acceptance Criteria: Conditions of Satisfaction User stories are often kept in Product Backlogs, and although those are frequently managed in an electronic format, the 3 C s of a user story from Ron Jeffries helps reinforce key principles of working with this format of requirements. Card Generally an index card, it forces us to keep user stories brief. Conversation User stories are a placeholder for conversation and do not contain all necessary specifications Confirmation A reminder to get Acceptance Criteria, how we can confirm our solution is built properly The commonly accepted approach to Product Backlogs and the hierarchy of Agile requirements follows a three-tier method (Epics>Features>Stories). Epics and Features are used to describe the larger intended behavior, but all the detailed implementation work is described via stories, which are the primary elements of the team backlog. Most stories arise from program features, but many others emerge from the local team context. Each story is a small, independent behavior that can be implemented incrementally, and provides some value to the user. To assure that every iteration delivers new value, stories are split as necessary so they can be completed in a single iteration. Stories are not requirements, in that they are generally negotiable and represent a statement of intent rather than a contractual (internally or externally) specific behavior. However, through acceptance criteria [and other analysis and modeling techniques], stories get more specific as they are implemented, helping to assure system quality. This article describes user stories, each of which answers the question who does what with this system, and why do they do it?, as well as technical stories, which teams use to describe other types of necessary system behavior. -- Scaled Agile Framework

3 TYPES OF BACKLOG ITEMS The thought leaders behind the Scaled Agile Framework allude to the idea that product backlogs have more than user stories within them. There are 3 common types of backlog items. User Stories Demonstrable working software that is valuable to the product s end-users and can be accepted by the team s Product Owner. Foundation Stories Demonstrable working software that could not be completed within the confines of a User Story and can be verified by the team as complete. aka Technical Stories Spikes Information or a Decision that is required to move forward with other items within the Product Backlog and can be summarized and verified by the team. It may also be worth including a backlog item for Defect. Keep in mind that defects should only be considered defects if they have escaped an iteration or made it into production. Consider the following when determining how to handle production defects within an Agile team. Is it critical to have this fixed ASAP? - If yes, then stop work in progress move forward and fix it - If no, keep on reading Can it wait until the next release the Agile team has planned? - If no, then consider a fast-track option for getting it done. - If yes, then keep on reading Is it more or less important than something else on that team s currently defined Release Plan? - If yes, then add it to the backlog in correct priority order and update the Release Plan accordingly - If no, then simply add it to the backlog and get to it when the time is right INCLUDING NONFUNCTIONAL REQUIREMENTS Nonfunctional requirements (NFRs) are often overlooked in traditional analysis and it is critical for them to be incorporated into the overall body of Agile requirements. Nonfunctional requirements frequently appear in one of the following ways: Through Acceptance Criteria When the nonfunctional element pertains only to the function described within the user story. This approach can also be used with the same NFR applies to a small number of stories. The risk of repeating a NFR multiple times is that it can be transcribed inaccurately and lead to conflicting requirements. As Constraints of the Product When NFRs pertain to the system as a whole (or large functional areas), abstract them from the product backlog and consider them global acceptance criteria that govern the way the solution is designed and implemented. Within the Definition of Done This is another option when the NFR applies to all other backlog items, and it will be referenced at the conclusion of each sprint. Contained in Tests & Other Supporting Details Writing tests that ensure the NFR is working will provide assurance that the product meets requirements. Tests are just one way to elaborate additional story details, and other supporting models may contain NFRs.

4 AS DEFINED IN THE IIBA BABOK Guide, Version User Stories Purpose User Stories are a brief description of functionality that users need from a solution to meet a business objective Description A user story is a textual description of things that the solution needs to allow users to do. User stories are typically a sentence or two that describes who uses the story, the goal they are trying to accomplish, and any additional information that may be critical to understanding the scope of the story Key Features A user story includes a short description of the problem to be solved. This is from the perspective of the user. The only detail that needs to be included is information that reduces the risk of misunderstanding by developers that create the estimate. A user story includes: Actor: Stakeholder who benefits from the user story. Description: A high-level overview of what functionality the user story includes. Benefit: The business value the story delivers. A user story should also have defined Acceptance and Evaluation Criteria (9.1) When to Use.1 Advantages User stories create an environment of customer ownership of features and prioritizations in an incremental, iterative development environment. They may eliminate the need to provide functional requirements in some environments. User stories also require that the value delivered by the story be clearly articulated..2 Disadvantages They may not be the best technique for some environments with regulatory restrictions or when an organization mandates documentation. This modeling technique may not be effective when participants are not co-located. This technique does not explicitly address how to document nonfunctional requirements.

5 The Lifecycle of a User Story ASPECTS OF THE LIFECYCLE Creating User Stories All user stories start as ideas. Once the idea is in place, user stories can be written by anyone on the team. Product Owners are the ones accountable for validating the content of the story, prioritizing it, and ultimately accepting it as something that should be contained within the team s backlog. Early on, new user stories are often written within Story Writing Workshops, but as teams progress through sprints it is more common for new stories to be written in an ad-hoc fashion. These new stories are considered to be ROUGH CUT user stories. They are just good enough to capture the idea, and are set aside for future conversation. Refining User Stories Rough Cut user stories are not fit-for-use in a Sprint Planning session. They likely do not have comprehensive Acceptance Criteria, nor do team members have a shared understanding of their approach for delivering the value the backlog item requires. There are a plethora of techniques for refining user stories and the level of formality teams use to prepare user stories for delivery will vary based on the maturity of the team. The discipline to keep a well-refined backlog deep enough to sustain the flow of an incremental delivery cadence requires an investment of time. The goal for teams should be to have 1 sprint s worth of stories ready to commit to, and at least 3 or 4 additional sprint s worth of stories estimated, prioritized, and sized small enough to start and finish in a single iteration. Note, this means 1 sprint of ready stories beyond the backlog items the team has already committed to delivering. Committing to User Stories Sprint Planning and the moment that a team commits to a user story is the moment that the scope of the story is locked-down for delivery. In order to make accurate and authentic commitments team members should strive to know 90% of what they need to know about the backlog item. There are 4 considerations that can help teams determine if a story is ready to be committed to. 1. Is there shared understanding? Has the team ensured everyone truly has the same shared understanding of the user story and its acceptance criteria? Additionally, has the team defined unified for constructing the solution that will meet the user s needs? 2. Is it sized appropriately? Has the team checked the size of the story to ensure it is sized consistently based on known factors? 3. Is there enough knowledge to plan the tasks? If asked to complete task planning for the story, do all team members know enough to breakdown tasks sized to 4-6 hours? 4. Are all external dependencies fulfilled? Do any other Agile teams, waterfall projects, departments, or vendors have to do something in order for the team to complete their work? If so, has that work been completed? If not, it may not be the right time to commit to the user story.

6 Delivering User Stories The actual construction and validation of value. Team members are completing the final levels of analysis and design as well as coding, testing, and integration tasks necessary to complete the user story. Simply executing the tasks is not enough. As work completes, the team should be continuously confirming the incremental creation of value. The delivery of user stories culminates with the demo at the end of the sprint where the team showcases the solution created and asks for feedback and acceptance from key stakeholders. This is a prime time for team members to uncover additional user stories. Deploying User Stories When there are high levels of technical excellence and continuous delivery in place, it is possible that the value delivered by the user story could be deployed at the end of every sprint. However, it is more common that several sprints worth of work are combined together into a single release. REFINEMENT REQUIRES A CADENCE There are two common ceremonies teams use in order to keep backlog items ready for Sprint Planning. Backlog Refinement Workshops One or two set times within the team s sprint schedule where all team members come together to collaborate on backlog items that are likely to be completed within the next 4-6 weeks (2-3 sprints ahead). Looking further out than 4-6 weeks runs the risk that the team invests time elaborating details for work that may never be done. It is not uncommon for teams to spend upwards of 4-hours of each sprint looking ahead and refining upcoming backlog items. When setting aside time for Backlog Refinement Workshops, do so in a minimum of 2-hour increments in order to allow enough time for detailed collaboration. Avoid scheduling sessions longer than 3-4 hours long in order to avoid burn-out. Target the stories planned for n+2 iterations ahead. Story Review Session A brief, perhaps 30-minute, session that the team has mid-sprint where the focus is reviewing the stories n+1 sprints ahead. The purpose is to ensure that the stories for the next sprint are ready to for sprint planning. Think of it as a requirements verification session where team members are checking to see if the backlog items are fit-foruse in the next step of the process. If it is found that backlog items are not ready, then this would be the appropriate time to refactor the release plan and re-set expectations for delivery.

7 Supporting & Elaborating User Stories USER STORIES ARE NOT ENOUGH A user story does not contain enough detail and specifications for a team to go forward and construct a solution. At a minimum, it is necessary for team members to collaborate and gain a shared understanding of the backlog item s intent and their approach for delivering the value. High-maturity Agile teams may not formally capture the results collaboration, however, it is recommended that some form of documentation (or work products) be created in order to reinforce the memory of team members. The work products may range from low-fidelity sketches, models, and notes on a single sheet or paper or be as comprehensive as a mini-frd (functional requirements document). TECHNIQUES TO CONSIDER There are countless techniques for teams to consider when determine the best way to support user stories. Formal IIBA defined techniques include: Assumptions, Dependencies & Constraints Business Rules Analysis Data Dictionary & Glossary Data Modeling Scenarios & Use Case Modeling Context Diagrams Document Analysis Benchmarking Interface Analysis Prototyping Decision Analysis Process Modeling Functional Decomposition Agile teams should not limit themselves to formal business analysis techniques, and should look for additional user-centric approaches that define context and set clear expectations for what the story s intent. Given, When, Then Most closely associated with Behavior Driven Development (BDD), Given-When-Then phrasing can be used for defining acceptance criteria as well as outlining supporting scenarios for user stories. Given When Then Some context Some action is carried out An observable result or consequence A shopper is logged in They proceed to check-out Pre-fill payment and shipping information with their default settings. Use Cases It is important to understand that use cases and user stories are not the same. Use cases tend to have a longer shelf-life an incorporate a larger scope than a single user story. Use case modeling at a high-level can be used to identify new user stories (each branch/alternate flow of a use case could be a separate user story), or more detailed use cases can be used to define specific user-system or system-system interactions for a single user story. The IIBA BABOK Guide, Version 2 defines the following elements to a use case: Name Actor(s) Preconditions Flow of Events Post-Conditions Relationships

8 An example use case: NAME Login Shopper ACTOR(S) Shopper, Web Browser, Commerce Engine, Web PRECONDITIONS Shopper is on the site Shopper is viewing the login page or a login modal FLOW OF EVENTS 1. [WEB BROWSER] Has a cookie stored that identifies the shopper 2. [COMMERCE ENGINE] Provides browser the username for the shopper 3. [WEB BROWER] Pre-fills the shopper s username in the field 4. [SHOPPER] Enters correct password and clicks submit 5. [WEB BROWSER] Passes data to commerce engine 6. [COMMERCE ENGINE] Authenticates the shopper POST-CONDITION Shopper Identification Cookie is set Session is started If origination was Login Page, shopper is directed to Home Page with masthead displaying personalized information. If origination was Login Modal, modal is closed and page is refreshed and now displays personalized information. RELATIONSHIPS Alternate Flows 1. No Shopper Identification cookie is present 2. Shopper enters incorrect password 3. Shopper changes pre-filled username 4. Commerce engine fails to respond Specifications by Example This technique is exceptionally useful for complex data rules and scenarios and is best understood through an example. The User Story As a shopper, I want to get deeper discounts if I spend a lot, so that I am rewarded for my loyalty and frequent shopping. Given When Then Shopper has an account Spending thresholds are met Loyalty discount % changes Shopper is logged in Cart is viewed Loyalty discount is displayed Specifications by Example Total Spending in Calendar Year Loyalty Discount Percentage $ $ % $ $ % $ $ % $1, $2, % $3, %

9 Story Mapping Story mapping combines the traditional analysis techniques of Process Modeling and Functional Decomposition. Team s leveraging this technique can create context and continuity among a set of user stories as well as visually classify stories into different target releases. There are Step 1: Map the Process Teams must first select the process that they wish to analyze and draw the process flow. Recurring Product s View Product Add to s Manage Preferences Delivery Initiated Step 2: Identify User Stories After mapping the process, identify the user stories that need to be written (rough cut) stories are good enough. Note, in the example below, only the story names are listed. View Product Add to s Manage Preferences Delivery Initiated Available Item Search Promotions Pricing Subscribe for Item Quick-Set Frequency Quick-Set Next Delivery View s Set Defaults Change Delivery Date Change Frequency Change Payment Details Change Delivery Address Cancel Group s Delivery Coming Soon Delivery Sent Notification Delivery Confirmation Step 3: Prioritization Prioritize the column of stories under each step of the process. View Product Add to s Manage Preferences Delivery Initiated 1. Available 2. Pricing 3. Promotions 4. Item Search 1. Subscribe for Item 2. Quick-Set Frequency 3. Quick-Set Next Delivery 1. View s 2. Cancel 3. Change Frequency 4. Change Payment Details 5. Change Delivery Address 6. Change Delivery Date 7. Group s 8. Set Defaults 1. Delivery Coming Soon 2. Delivery Sent Notification 3. Delivery Confirmation

10 Step 4: Release Strategy Arrange the stories into swim lanes that show which backlog items are targeted for each release. View Product Add to s Manage Preferences Delivery Initiated 1. Available 2. Pricing 3. Promotions 4. Item Search 1.Subscribe for Item 2.Quick-Set Frequency 3.Quick-Set Next Delivery 1.View s 2.Cancel 3.Change Frequency 4.Change Payment Details 5.Change Delivery Address 6.Change Delivery Date 7.Group s 8.Set Defaults 1.Delivery Coming Soon 2.Delivery Sent Notification 3.Delivery Confirmation WORK PRODUCTS VS. DELIVERABLES User stories have a very short shelf life. They exist for the pure purpose of creating an product increment that can be demoed for review and acceptance. In practice, keeping archives of user stories for knowledge management and production support needs is not useful. It is important for teams and organizations to distinguish between work products and deliverables. Work Products The documentation and artifacts that are needed by teams in order to get the user story demoed and accepted by the Product Owner. Deliverables Organizationally required documents for compliance, audit, transition management, or knowledge management purposes. The goal is to make work products (or short-term artifacts) as lean as possible. (What is the bare minimum a team needs to get the solution working?) Deliverables are likely something that is consistent across multiple teams. When creating deliverables, wait until you ve confirm the solution is working as desired. This will minimize the amount of rework and content updates needed after a deliverable has been created.