Chapter 1A: Scrum and User Stories PDF

CHAPTER 1A 1.1 Introduction to Agile 1.2 Scrum 1.3 User Stories 1 1.1 Introduction to Agile Problems with the traditional methods Agile values and principles 2 In a typical software development project…...

CHAPTER 1A 1.1 Introduction to Agile 1.2 Scrum 1.3 User Stories 1 1.1 Introduction to Agile Problems with the traditional methods Agile values and principles 2 In a typical software development project… 3 Problems Too expensive Too big Massive documentation Too slow Too inflexible Massive bureaucracy 4 Requirements Always changing Design Implementation Ski ppe Takes Testing d too long Dre Deployment ade Maintenance 5 6 7 Agile Values Individuals & interactions over processes & tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan 8 Individuals & Interactions over Processes & Tools 9  Working Software over Comprehensive Documentation 10 Customer Collaboration over Contract Negotiations 11 Responding to Change over Following a Plan 12 13 Agile Methodologies Scrum Extreme Programming (XP) Lean Software Development Agile Modeling (AM) Adaptive Software Development (ASD) Dynamic Systems Development Method (DSDM) Feature Driven Development (FDD) The Crystal Methodologies 14  Agile is an umbrella. Methodologies are implementations. 15 16 Agile vs Waterfall Process 17 1.2 Scrum Introduction Values Roles Events Artifacts 18 Introduction to Scrum An iterative project management methodology Suitable for any project-based work Provides a framework for – business areas to identify and prioritize work required, – project teams to commit to the subset of priority items that can be delivered in each “sprint” 19 The Scrum Process Created by Jeff Sutherland in 1993 Based on Takeuchi and Nonaka’s work, which compared high-performing, cross-functional teams to the scrum formation used by Rugby teams. 20 Scrum Theory Founded on empirical process control theory (empiricism): – Knowledge comes from experience and making decisions based on what is known. Employs an iterative, incremental approach to – optimize predictability – control risk 21 3 Pillars for Empirical Process Control Transparency Inspection Adaptation 22 23 Scrum Roles 24 Product Owner The customer representative Solely responsible for managing the Product Backlog To turn the vision into a workable product backlog for the team to execute Manage the ROI of the software under development Should demand efficiency and excellence from the team 25 ScrumMaster’s Role (1) Work to build and maintain a high-performing team Not the team manager or leader, but the enabler that ensures the team works at optimum effectiveness Keeps the team focused and on track Ensure that Scrum practices are followed by the team Be the interface point among management, customer and Scrum Team 26 ScrumMaster’s Role (2) Providing a key check and balance – High team velocity VS team’s health Increase velocity by – Removing impediments – Monitoring team health – Providing status updates to team A change agent in the organization Servant leadership 27 ScrumMaster’s Daily Tasks Remove impediments Break up fights Act as a team mom Report team data Facilitate Help out where needed Educate the organization Drive organizational change 28  Development Team Consists of developers or programmers. Deliver working software (increments) Depend on the ScrumMaster and Product Owner to deal with the noise Empowered to organize and manage their own work 29 Development Team Characteristics Self-organizing Cross-functional Accountability belongs to the entire team – Granted that individual members may have specialized skills and areas of focus – All members have the title “Developer” – Does not have sub-teams 30 Team Members’ Tasks Testing, analysis, architecture, design, programming, planning, estimation, etc. Initially, not every team member will have every single one of these skills, but they will have a subset of them, and they will strive to gain more skills over time. Team members identify tasks, estimate tasks, “sign up” for tasks, perform the tasks, and track their status toward completion. 31 Team Members’ Additional Responsibilities 1. Go to the PO for domain information and decisions 2. Work with the architecture owner to evolve the architecture 3. Follow enterprise conventions and leverage and enhance the existing infrastructure 4. Lead meetings 32 Scrum Roles ScrumMaster – To keep the Scrum process running smoothly without dictating solutions Product Owner – To steer the team in the best direction based on business value Scrum Team – Learn to be good team members, which involves cultivating cross-functional attitude, learning new skills and working on tasks that might be new to them. 33  Interdependencies among Scrum Roles Without a product owner, the team risks missing the mark. Without a ScrumMaster, the team risks burnout. Without committed team members, the project itself is at risk. 34  Competencies of a ScrumMaster Builds trust Helps others see issues Provides leadership through influence Likes working with people Is calm under pressure 35  Competencies of a Product Owner Can determine what customers mean by listening to what they ask for Can bring stakeholders and customers to convergence on features and functionality Has product management expertise Has basic financial experience Has a background in the industry of the application under development 36  Competencies of a Team Member Has an open mind Is looking to improve and to help others become better Has a team attitude Is humble and respectful 37 Great developers care deeply about the code. Great teams care deeply about each other. - Declan Whelan 38 Scrum Events / Ceremonies 39 1. Sprint Why iterative? Sprint == Iteration Timebox: 1 – 4 weeks 40 PDCA Scrum Sprint 41 2. Sprint Planning Held at the beginning of each sprint. The product owner and the team o Discuss the highest priority items in the product backlog and o Brainstorm a plan to implement the items 42 3. Daily Scrum Meeting 1. What I did yesterday … 2. What I am doing today.. 3. What is blocking me.. 43 Purpose of Daily Scrum Meetings Team members o Make their progress visible o Thus, can inspect and adapt toward meeting goals Scrum Master o Facilitate o Keep conversation from delving into problem solving o Record any obstacles that team members cannot fix 44 4. Sprint Review Meeting The team, product owner, Scrum Master, stakeholders o Review the features o Give feedback about the emerging product o Discuss new ideas to add to the product backlog 45 5. Retrospective The final meeting in each sprint Team members discuss the events of the sprint and identify o What worked well o What didn’t work well and take on action items for any changes that they’d like to make for the next sprint 46 Timeboxes in Scrum (15 mins) (2-4 hrs) RETROSPECTIVE (15 – 30 mins) 47 Scrum Artifacts Product Backlog Sprint Backlog Product Increment 48 49 1. The Product Backlog The product owner’s wish list Owned by the product owner who – Maintains it – Prioritizes it 50 51 Product Backlog Example 52 2. The Sprint Backlog Owned by the team Includes – The product backlog items committed to in sprint planning – Subsequent tasks – Reminders Team members may – Update it to reflect remaining hours on tasks – Add, remove or change tasks as the sprint is underway 53 3. The Product Increment A set of features or other deliverables completed by the team in the sprint Should potentially be shippable (high enough quality to give to users) – The PO is responsible for accepting the product increment during each sprint, according to the agreed-upon Definition of Done and acceptance criteria for each sprint deliverable 54 Characteristics of Scrum Prototype leads to product Rapid feedback Reduced risk 55 Definition of Done (DoD) Members must have a shared understanding of what it means for a Product Backlog item to be complete 56 57 58 59 60 1.3 User Stories Writing User Stories INVEST Criteria Patterns for Splitting User Stories Hierarchy of User Stories Note: Refer to Appendix 1.1 for detail notes 61 A User Story Card: 62 User Story Originated in XP. A brief statement of intent that describes something the system needs to do for the user. The Agile replacement for software requirements statements. Features in Scrum’s product backlog are described in terms of user stories now. 63 64 User Story: Canonical Form As a I want to so that where : Who is performing the action : The action to be performed by the system : The value achieved by the activity. 65 66 User Story Examples 67 Attributes of a Good Story 68 “The story is the unit of functionality in an XP project. We demonstrate progress by delivering tested, integrated code that implements a story. A story should be understandable to customers, developer-testable, valuable to the customer, and small enough that the programmers can build half a dozen in an iteration.” - Beck and Fowler (2005) 69 70 71 INVEST Criteria Trade-Offs? Independent vs Small Valuable vs Small 72 Requirements vs Use Case vs User Story Example Problem Statement The client has requested the ability to search for health care providers by provider specialty within a doctor selection site. Refer to Appendix 1.1 73 Epics Large, compound stories Usually a vague concept of something we want to do for a user Too big to be implemented within an iteration. Must split them into smaller stories Watch out for compounds and conjunctions in the stories, e.g.: and, or, if, when, but, then, also, as well as, plus commas and so on. 74 Epic Example: The subscribers should be able to practice mock tests, and when the subscription expires they should be able to renew so they can continue their practice. This can probably be split into: As a (registered) subscriber, I should be able to practice mock tests so that I can test my understanding. As a (returning) subscriber, I should be able to renew my expired subscription so that I can practice mock tests. 75 Patterns for Splitting User Stories 1. Workflow Steps 2. Business Rule Variations 3. Major Effort 4. Simple/Complex 5. Variations in Data 6. Data Entry Methods 7. Defer Performance 8. Operations (e.g. CRUD) 9. Break Out a Spike Patterns for Splitting User Stories - Agile For All.htm 76 #1 As a content manager, I can publish an article to the corporate website so that the general public can access it. 77 Epic with Workflow Example: As a shopper, I want to pay online for the items on my cart. This can probably be split into: As a shopper, I want to choose my method of payment. (Want to complicate it more? As a shopper, I want to pay through multiple payment modes.) As a shopper, I want to receive an email notification acknowledging the receipt of my payment. As a shopper, I want to receive email notification with my order details. 78 #2 As a customer, I can pay for my purchases so that I can own the items. 79 Epic with Business Rules Variation: Subscribers should be able to practice their mock tests. This can probably be split into: As a subscriber, I should be able to practice mock tests. As a subscriber, I want to choose the difficulty level of the mock test. As a subscriber, I want to see the results of my mock test in a text report. As a subscriber (age 50-plus), I should be able to practice mock tests with default large font size. 80 #3 81 Epic with Major Effort: As a shopper, I can pay for my purchases with MasterCard, VISA, Diners Club, or American Express. This can probably be split into: As a shopper, I want to pay for my purchases with a MasterCard. As a shopper, I want to pay for my purchases with a VISA card. As a shopper, I want to pay for my purchases with a Diners Club card. As a shopper, I want to pay for my purchases with an American Express card. 82 #4 83 Epic with Hidden Complexity: As an exam controller, I want to search subscribers. This can probably be split into: As an exam controller, I want to search subscribers who passed the exam between a range of dates.... by examination name.... by the subscriber's country.... by the range of marks scored. Etc. 84 #5 As a content manager, I can publish articles... … in English … in Mandarin … in Japanese 85 Epic with Variation in Data Output: As a subscriber, I want to see my mock tests performance dashboard. This can probably be split into: As a subscriber, I want to see my performance in mock tests as a line graph, so I can see the progress over previous tests. As a subscriber, I want to see my performance in mock tests as a bar chart, so I can see the progress over previous tests. As a subscriber, I want to see my performance line in mock tests compared to the average performance of others on a bar chart. 86 #6 87 #7 As a user, I can search for flights between two destinations... … (slow – just get it done, show a “searching” animation … (in under 5 seconds) 88 #8 89 Epic with High Level Operations: As an application administrator, I want to manage user accounts. This can probably be split into: As an application administrator, I want to create a new user account. As an application administrator, I want to reset a user password. As an application administrator, I want to deactivate a user account. Etc. 90 #9 91 Does the user story contain enough details for the developers to work on? How do we get User Story Detail? 92 Ron Jeffries’ Card, Conversation, & Confirmation Card – Represents 2-3 sentences used to describe the intent of the story. Conversation – Represents a discussion between the team, customer, product owner, and other stakeholders to determine the more detailed behavior required to implement the intent. Confirmation Represents the acceptance test, which is how the customer or product owner will confirm that the story has been implemented to their satisfaction. 93 User Story Detail Conveyed mainly through conversations – between the product owner and the team – team is involved from the beginning Additional details can be provided as an attachment to the user story. – a mock-up, spreadsheet, algorithm, etc The additional user story detail should be collected over time (JIT) – through discussions and collaboration – before and during development. 94 User Stories Benefits Mitigates the risks of delayed feedback due to small increments and frequent releases. Customer has the option to change his mind on the details or the schedule priority of any user story not yet implemented. Gives developers clear and precise acceptance criteria and ongoing feedback as they complete work. Promotes a clear separation of responsibilities between defining the “what” and the “how”. 95 Epic, Story, Sprint 96 Story Mapping 97 Agile Hierarchy of Requirements Themes Epics User Stories Tasks 98 99 Example of Tasks for a Story Story 51: Select photo for upload Task 51.1: Define acceptance test – Lee, Don, Bill Task 51.2: Code story – Lee Task 51.3: Code acceptance test –Bill Task 51.4: Get it to pass– Lee and Bill Task 51.5: Document in user help – Cindy 100  Story Decomposition Write the stories to create an account management page for an online retailer 101 User Story As a customer, I can manage my account so that … This Whatisdo you think? 102 Break the story down As a …, I can manage my orders As a …, I can As a …, I can manage my payment manage my account options As a …, I can manage my settings 103  Decompose the story “I can manage my payment options” As a …, I can manage my orders I can manage existing payment As a …, I can options As a …, I can manage my account manage my payment options I can add a credit card As a …, I can manage my settings 104  Decompose the story “I can manage existing payment options” As a …, I can I can edit an existing credit manage my orders I can manage card existing As a …, I can As a …, I can payment options I can delete an manage my manage my existing credit account payment options card I can add a credit card As a …, I can manage my settings 105  Decompose the story “I can manage my settings” As a …, I can manage my orders I can change As a …, I can As a …, I can my personal manage my manage my information account payment options I can reset my password As a …, I can manage my settings I can manage my address book I can change my email preferences 106  Task Decomposition As a …, I can manage my orders I can change As a …, I As a …, I can my personal I can modify can manage my information configuration manage my payment file account options I can reset my password I can edit existing As a …, I can addresses manage my I can manage my address I can modify settings book I can delete extension DLL existing I can change addresses my email preferences 107 The story “Edit existing addresses in my address book” decomposes into 2 tasks TASK NAME EST (HOURS) Modify Configuration File John 80 Modify Extension DLL Mike 50 108 Sample Task Breakdown Create a ConfigurationSettings singleton class Extract log settings from configuration file Expose settings for log as get methods Modify Expose settings for web service as get methods configuration file Refactor extension and test DLL to use ConfigurationSettings class As a … I can manage my Test configuration file and classes in unit tests account Extract web service settings from configuration file Modify extension DLL Identify customer acceptance tests Implement automated customer acceptance tests Execute automated customer acceptance tests 109 Estimate Task Sizes Configuration File NAME EST Create a ConfigurationSettings Singleton Class John 8 Extract log settings from configuration file John 12 Extract web service settings from configuration file John 20 Expose settings for log as get methods John 20 Expose settings for web service as get methods John 8 Refactor extension & test DLL to use Mike 20 ConfigurationSettings class Test configuration file and classes in unit tests Bart 8 Extension DLL NAME EST Identify customers acceptance test Mary 12 Implement automated customer acceptance test John 12 Execute automated customer acceptance tests Mike 6 110