SlideShare a Scribd company logo
Agile with SCRUM Overview and User Stories Peter Saddington, CSM CSP Enterprise Agile Coach Executive Editor AgileScout.com @agilescout
White Barrel LLC. © 2011 Peter Saddington Peter Saddington, CSP CSM Independent Enterprise Agile Coach Rally Software Agile Coach Executive Editor AgileScout.com Author –  Scrum Pocket Guide [email_address] +1.404.669.6662 www.agilescout.com www.scrumpocketguide.com Twitter:  @agilescout
Before we begin… A Standup! Let’s take a moment to introduce ourselves. What’s your name & project you’re working on? What is your level of experience with Agile? What do you hope to learn in this workshop? Write questions on Sticky notes as they occur to you and affix them to our  Learning Backlog . White Barrel LLC. © 2011 Peter Saddington
Free Swag = #win! White Barrel LLC. © 2010 Peter Saddington www.scrumpocketguide.com
Agile Manifesto Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan White Barrel LLC. © 2011 Peter Saddington www.agilemanifesto.org
Distilled Principles of Agile Manifesto Priority is to satisfy the customer Deliver working software frequently Business and development work together Working software is primary measure of success The team regularly reflects on work Build projects around motivated people White Barrel LLC. © 2011 Peter Saddington
Process Frameworks Waterfall White Barrel LLC. © 2011 Peter Saddington
Process Frameworks Iterative White Barrel LLC. © 2011 Peter Saddington
Process Frameworks Agile White Barrel LLC. © 2011 Peter Saddington
Agile vs Scrum vs Other Frameworks Agile is a mindset, there are several ways to implement Agile: XP – Extreme Programming DSDM – Dynamic Systems Development Method Scrum – lightweight team centric processes Lean – Manufacturing processes applied to software FDD – Feature centric processes White Barrel LLC. © 2011 Peter Saddington
Scrum Scrum is not an acronym, but a strategy in the game of rugby for getting an out-of-play ball back into play. White Barrel LLC. © 2011 Peter Saddington
Exercise – Batch vs Flow  Four volunteers, please! Round 1 Each person flips all pennies When done with entire batch, pass to next person Round 2 Each person flip one penny and pass to next person Keep flipping and passing until done Round 3 Each table creates their own rules to maximize penny flow/throughput in least amount of time White Barrel LLC. © 2011 Peter Saddington
Scrum Rules Scrum is a set of rules, procedures, and practices Improve the development environment Reduce organizational overheads Ensure iterative deliverables match user requirements White Barrel LLC. © 2011 Peter Saddington
Scrum Approach Work together as a whole team Focus on business priorities Time box short sprints and releases Commit and deliver value incrementally White Barrel LLC. © 2011 Peter Saddington
The Chicken and the Pig – A Story: Bacon and Egg Restaurant Chickens involved… Pigs are committed! White Barrel LLC. © 2011 Peter Saddington
How It All Starts A Scrum project starts with a vision of the system or product to be developed The vision might be vague at first… Perhaps stated in market terms rather than system terms… But it will become clearer as the project moves forward White Barrel LLC. © 2011 Peter Saddington
Scrum Roles Product Owner The single customer voice who establishes the vision, prioritizes the work and defines success criteria ScrumMaster The situational leader who empowers the team, facilitates the process, and removes impediments Cross-functional team The people who deliver the customer value White Barrel LLC. © 2011 Peter Saddington
Scrum Meetings Daily Scrum Sprint Planning Meeting Sprint Review Meeting* Demo Sprint Retrospective White Barrel LLC. © 2011 Peter Saddington
Scrum Artifacts User Stories Product Backlog List of functional and non-functional requirements Sprint Backlog Prioritized list of stories for a given sprint Sprint Burndown Chart A chart showing completion of stories over time Definition of done White Barrel LLC. © 2011 Peter Saddington
The Bottom Line Scrum is: Doing the simplest thing possible Getting a team what it needs and getting out of their way Removing any obstacle that is preventing a team from being productive and efficient White Barrel LLC. © 2011 Peter Saddington
Final Thoughts The core of Agile is the team Focus on the priorities first (most valuable) Communication Document throughout the process instead of all up front Review, review, review Define the “done.” White Barrel LLC. © 2011 Peter Saddington
User Stories – Better Practices A Quick Guide to Story Creation in Scrum Peter Saddington CSM, CSP Agile Scrum Coach
A Worldview White Barrel LLC © 2010 Peter Saddington
Roadmap White Barrel LLC © 2010 Peter Saddington
Why Not Requirements Documents? Complete specifications: Assume everything is knowable in advance Are time-consuming to write and tedious to read Treat learning as a “Change of Scope” Don’t lend themselves to iterative, incremental delivery process White Barrel LLC © 2010 Peter Saddington
User Stories are a Conversation User stories are: User or customer need Product description Used for planning A conversation piece  White Barrel LLC © 2010 Peter Saddington
User Stories Facilitate Conversation User*  – How do I describe what I want? Stakeholder  – What do I need in my product to be successful? PM  – How do I track and schedule this work? BA  – What are the details of this feature? UX  – How do I understand the users needs? Developer  – What are the details of the tasks I need to work on today? QA  – How do I validate this completed work? White Barrel LLC © 2010 Peter Saddington Adapted from Jeff Patton www.AgileProductDesign.com
Easy to understand  – Makes sense to the reader A (software/system) requirement  One or two sentences with value to the customer Written by the Customer  – PO or BA Refined by Development – Tasks and Technical Negotiable  – Conversation token Small and estimable – Small enough to estimate Testable – Should have acceptance criteria Becomes more detailed over time  – Iteration Planning White Barrel LLC © 2010 Peter Saddington A User Story Is
White Barrel LLC © 2010 Peter Saddington User Story Process Step #1 Step #2 Step #3
Define the user personas! What different types of customers/consumers interact with the system? What are their roles? White Barrel LLC © 2010 Peter Saddington Step #1 - Where do we start?
User Roles Various types of user personas Role Modeling Brain storming Organizing  Consolidating Refining Extreme Characters? White Barrel LLC © 2010 Peter Saddington User Role Modeling
Scenario :  You need to create a simple login and preferences mechanism for your corporate Twitter account Who are your users of this system? What are their roles? White Barrel LLC © 2010 Peter Saddington Exercise - Defining the Personas
White Barrel LLC © 2010 Peter Saddington Persona Definition Documentation?
Roadmap White Barrel LLC © 2010 Peter Saddington
Story Creation - Guidelines Stakeholders  write user stories Remember non-functional requirements Indicate the  estimated  size Indicate the  priority Include a unique identifier (if applicable) Go into a product backlog The product backlog is prioritized by value – Highest to lowest White Barrel LLC © 2010 Peter Saddington
Non-Functional Requirements Non-functional requirements should often be considered “constraints” on a system Can include: Performance Quality Accuracy Portability Reusability Maintainability Interoperability Capacity White Barrel LLC © 2010 Peter Saddington Adapted from Mike Cohn www.mountaingoatsoftware.com
INVEST Model I ndependent  – One user story should be independent of another (as much as possible). Dependencies between stories make planning, prioritization, and estimation much more difficult. N egotiable  – Details of the story can be worked out during an Iteration planning meeting. A story with too much detail can limit conversations (at times). V aluable  – Value to the customer. E stimable  – There needs to be enough detail for the developers to estimate a user story to allow prioritization and planning of the story. S mall  – A good story should be small in effort, typically no more than 2-3 person weeks of effort (smaller is better)! T estable  – User stories should be testable with certain acceptance criteria. Saying something like  “software should be easy to use” is not helpful. White Barrel LLC © 2010 Peter Saddington Bill Wake’s INVEST Model
Ron Jeffries 3 C’s Card  – Stories written on note cards with annotations as needed (estimates, notes, etc) Conversation  – Details behind story come out through conversations with the Product Owner Confirmation  – Acceptance tests confirm the story was coded correctly White Barrel LLC © 2010 Peter Saddington
Four Main Components of a Story ( Given ( AS A ) ) –  “As a business owner…” / “Given a new list…” ( When ( I WANT ) ) –  “I’d like the ability to…” / “We need a function to…” / “When a customer clicks on…” / “When a dropdown opens…” ( Then ( SO THAT ) ) –  “So that I can…” / “So that the customer can…” / “Then the customer should see…” / “Then the dropdown list should…” ( Acceptance Criteria ) – Verifiable and testable criteria that can be tested based on THEN clause. Or Simply:  “As a <user type>, I want to <function> so that I can <business value> White Barrel LLC © 2010 Peter Saddington
1. Given ( Given ( AS A ) ) –  “As a business owner…” / “Given a new list…” We want users to be tangible with needs Build out “Personas” or “User Roles” – Standard user definitions (Sacred – Added with purpose) Avoid generic terms White Barrel LLC © 2010 Peter Saddington
2. When ( When ( I WANT ) ) –  “I’d like the ability to…” / “We need a function to…” / “When a customer clicks on…” / “When a dropdown opens…” This is the meat and potatoes of the story This is where you describe the functions White Barrel LLC © 2010 Peter Saddington
3. Then ( Then ( SO THAT ) ) –  “So that I can…” / “So that the customer can…” / “Then the customer should see…” / “Then the dropdown list should…” This is to show the intrinsic  value  of the story The  value  is to the persona, user, or author White Barrel LLC © 2010 Peter Saddington
4. Acceptance Criteria ( Acceptance Criteria ) – Verifiable and testable criteria that can be tested based on THEN clause. These are essentially tests – Conditions of satisfaction Example: As a user, I can cancel a reservation. Verify that a premium member can cancel Verify that a email confirmation is sent Verify that the hotel is notified of any cancelation These acceptance criteria can become developer tasks White Barrel LLC © 2010 Peter Saddington
4a. Acceptance Stories ( Acceptance Stories ) – Verifiable and testable criteria written in acceptance test form. Scenario 1: TITLE GIVEN [context] And [some more context] When [event] Then [outcome] And [another outcome] White Barrel LLC © 2010 Peter Saddington
4b. Acceptance Confirmation ( Acceptance Confirmation ) – Verifiable and testable criteria written in “Success” and “Failure” terms Success – valid user logged in “ Remember my user name” selected – store cookie / automatic login next time “ Remember my user name” not selected – force login next time Failure – display message: “ Email address in wrong format” “ Incorrect password, please try again” “ Service unavailable, please try again” Etc. White Barrel LLC © 2010 Peter Saddington
Exercise – 99 Balloons Let’s form some teams! Round 1 Recreate my balloon with: 2 round eyes, a triangle nose, and a semi-circle mouth  2 minutes! Go! Round 2 How can you improve for the next iteration? Round 3 How did you change how you worked this time around? White Barrel LLC. © 2011 Peter Saddington
User Interviews Select right interviewees Ask open-ended, context-free questions Questionnaires Larger population of users When you need specific answers to questions Observation Best for in-house developments Story writing workshops White Barrel LLC © 2010 Peter Saddington Step #2 – Gathering User Stories
Scenario :  You need to create a simple login and preferences mechanism for your corporate Twitter account We’ve determined our users… Let’s refine the set of user stories White Barrel LLC © 2010 Peter Saddington Exercise – Refine the User Stories
Roadmap White Barrel LLC © 2010 Peter Saddington
Product Backlog to Release Backlog A prioritized list of features for the given product Stories are implemented based on their priority The TOP priority Features are put into iterations first Changes to the iterations are OK After stories are built they go into a release backlog White Barrel LLC. © 2010 Peter Saddington
Prioritization Factors to Consider Financial value of features Costs of implementation Amount of risk removed / added Training on new features PO should be enabled  White Barrel LLC. © 2010 Peter Saddington
MoSCoW Method M  – MUST have (Critical for success) S  – SHOULD have if possible (If not time critical) C  – COULD have if it does not affect anything else (Include if little development cost) W  – WON’T have this time, but WOULD like in future White Barrel LLC © 2010 Peter Saddington MoSCoW method - Dai Clegg of Oracle UK for DSDM
M & S of MoSCoW M  – MUST have (Critical for success) Essential - key stakeholders needs will not be satisfied if this requirement is not delivered and the timebox will be considered to have failed S  – SHOULD have if possible (If not time critical) Important - but if not delivered within the current timebox, there is an acceptable workaround until it is delivered during the next sprint White Barrel LLC © 2010 Peter Saddington
C & W of MoSCoW C  – COULD have if it does not affect anything else (Include if little development cost) “ Nice to have” – this is estimated to be possible to complete in the timebox but will be de-scoped if an underestimation has occured W  – WON’T have this time, but WOULD like in future Will not be delivered within the timebox White Barrel LLC © 2010 Peter Saddington
Kano’s Model of Quality Objective and Subjective Quality Must-haves – Same as “M” in MoSCoW One-dimensional – “The more of this I get, the better.” Delighters – Great to haves White Barrel LLC © 2010 Peter Saddington Noriaki Kano – Theory of Product Development
Kano’s Model - Example In Agile – Objective quality is non-negotiable Subjective quality – Perception of quality To accurately assess subjective quality, the Product Owner MUST know the customers (primary users) One user’s “delighter” may leave others apathetic One user’s “must have” is useless to others White Barrel LLC © 2010 Peter Saddington Jeff Paton – www.Agileproductdesign.com
Prioritization Sliders White Barrel LLC. © 2010 Peter Saddington
Manage the backlog by: Sorting stories by user persona Sorting stories by highest priority (value) Review stories for completeness Asking the 4 “WHYs” for business value Why do you want…? [As a] Customer Service Representative [I want] to have a button  [So that] I can go to the next screen… White Barrel LLC © 2010 Peter Saddington Step #3 – A.C. and Backlog Priority
Scenario :  You need to create a simple login and preferences mechanism for your corporate Twitter account We’ve determined our users… We’ve refined the set of user stories Let’s put A.C. and priority White Barrel LLC © 2010 Peter Saddington Exercise – Stories to Backlog
Roadmap White Barrel LLC © 2010 Peter Saddington
Themes to Tasks White Barrel LLC © 2010 Peter Saddington
Tasks Warm Up Exercise What are all the things you did to get ready to be at work today? Starting from the moment you woke up to arriving here. Take a sheet of paper and write them down! White Barrel LLC © 2010 Peter Saddington
Tasks vs Tools Exercise Share with the group some example lists What are common themes and tasks? What was different? White Barrel LLC © 2010 Peter Saddington
Goals, Tasks, Tools White Barrel LLC © 2010 Peter Saddington
User Stories are Tasks or Tools White Barrel LLC © 2010 Peter Saddington
Stories Satisfy User NEEDS First! White Barrel LLC © 2010 Peter Saddington
Start with specific personas Write closed stories first Write stories collaboratively  White Barrel LLC © 2010 Peter Saddington Simple Guidelines for Good Stories
Exercise – Creating at a Story Ta ke a current feature your team is aware of  Each team member writes the story Share  Discuss – Implications / Constraints / Missed AC Review White Barrel LLC © 2010 Peter Saddington
Roadmap White Barrel LLC © 2010 Peter Saddington
Epic User Stories Causes for Story Size Stories cover too much information Story writers do not have the needed domain knowledge Stories have uncertainty due to dependence on new technology Story writers cannot articulate exactly what they want White Barrel LLC © 2010 Peter Saddington
Breaking Up Epics Split  – Slice stories up into different scenarios Spike – Too many unknowns? Time-box a spike and take a deep dive into the technology or domain Stub – Part of a story known and part unknown. Fake it with a stub! Work on the known part up till the unknown. Time box – The PO knows they need something, but until they get it, not sure if it’s right  White Barrel LLC © 2010 Peter Saddington
Splitting for Value - Three Rules  When breaking down epics, remember: Split stories for value – No value? Hard to prioritize Split a story that gets you more equally sized small stories Split an epic that lets you deprioritize or throw away a story White Barrel LLC © 2010 Peter Saddington
Exercise – Breaking Up Epics Let’s take an example from our existing backlog White Barrel LLC © 2010 Peter Saddington
Suggestions for Splitting Up Epics Handle empty scenarios and core functions first Happy path, then alternate flows / exceptions Single option, then add additional options Simple (or no) UI, then add bells / whistles Transient case (no memory between sessions) before persistence Static elements, then dynamic based on content User specified, then more automation White Barrel LLC © 2010 Peter Saddington
Roadmap White Barrel LLC © 2010 Peter Saddington
Notes on Bug or Issue Tracking Steps to Reproduce / Recreate the Bug Actual Results Expected Results Any other details as appropriate White Barrel LLC © 2010 Peter Saddington
Exercise – Baseline Story Estimation Different Stories in different sizes (1,2,3,5,8…) What was the estimated size? What were the complexities of that story? Does this story need a re-write? What was missed? Complete for sizes White Barrel LLC © 2010 Peter Saddington
Questions? White Barrel LLC © 2010 Peter Saddington

More Related Content

What's hot

How to Break the Requirements into User Stories
How to Break the Requirements into User StoriesHow to Break the Requirements into User Stories
How to Break the Requirements into User Stories
ShriKant Vashishtha
 
How to write good user stories
How to write good user storiesHow to write good user stories
How to write good user stories
Jose E. Rodriguez Huerta
 
User Stories
User StoriesUser Stories
User Stories
Tathagat Varma
 
Effective User Stories
Effective User StoriesEffective User Stories
Effective User Stories
Derek Neighbors
 
User Story Mapping (2008)
User Story Mapping (2008)User Story Mapping (2008)
User Story Mapping (2008)
Jeff Patton
 
Certified Scrum Product Owner: class desk, posters and photos
Certified Scrum Product Owner: class desk, posters and photosCertified Scrum Product Owner: class desk, posters and photos
Certified Scrum Product Owner: class desk, posters and photos
Alexey Krivitsky
 
User Stories Fundamentals
User Stories FundamentalsUser Stories Fundamentals
User Stories Fundamentals
Moisés Armani Ramírez
 
Agile User Stories
Agile User StoriesAgile User Stories
Agile User Stories
kahgeh75
 
User Stories explained
User Stories explainedUser Stories explained
User Stories explained
Martin Lapointe, M.T.I.
 
User Story
User StoryUser Story
User Story
Sunil Jakkaraju
 
User Story Mapping 101
User Story Mapping 101User Story Mapping 101
User Story Mapping 101
Martin Etmajer
 
User Story Splitting
User Story SplittingUser Story Splitting
User Story Splitting
trishly
 
User Story Maps: Secrets for Better Backlogs and Planning
 User Story Maps: Secrets for Better Backlogs and Planning User Story Maps: Secrets for Better Backlogs and Planning
User Story Maps: Secrets for Better Backlogs and Planning
Aaron Sanders
 
Introducing Agile User Stories
Introducing Agile User StoriesIntroducing Agile User Stories
Introducing Agile User Stories
Ram Srivastava
 
User Story Splitting.pptx
User Story Splitting.pptxUser Story Splitting.pptx
User Story Splitting.pptx
Paul Boos
 
User story and splitting workshop
User story and splitting workshopUser story and splitting workshop
User story and splitting workshop
Brian Sjoberg
 
Cheat Sheet: 8 ways to split your user stories
Cheat Sheet:  8 ways to split your user storiesCheat Sheet:  8 ways to split your user stories
Cheat Sheet: 8 ways to split your user stories
Payton Consulting
 
Vertical Slicing
Vertical SlicingVertical Slicing
21 Story Splitting Patterns
21 Story Splitting Patterns21 Story Splitting Patterns
21 Story Splitting Patterns
Kent McDonald
 
Agile Story Writing
Agile Story WritingAgile Story Writing
Agile Story Writing
Intelliware Development Inc.
 

What's hot (20)

How to Break the Requirements into User Stories
How to Break the Requirements into User StoriesHow to Break the Requirements into User Stories
How to Break the Requirements into User Stories
 
How to write good user stories
How to write good user storiesHow to write good user stories
How to write good user stories
 
User Stories
User StoriesUser Stories
User Stories
 
Effective User Stories
Effective User StoriesEffective User Stories
Effective User Stories
 
User Story Mapping (2008)
User Story Mapping (2008)User Story Mapping (2008)
User Story Mapping (2008)
 
Certified Scrum Product Owner: class desk, posters and photos
Certified Scrum Product Owner: class desk, posters and photosCertified Scrum Product Owner: class desk, posters and photos
Certified Scrum Product Owner: class desk, posters and photos
 
User Stories Fundamentals
User Stories FundamentalsUser Stories Fundamentals
User Stories Fundamentals
 
Agile User Stories
Agile User StoriesAgile User Stories
Agile User Stories
 
User Stories explained
User Stories explainedUser Stories explained
User Stories explained
 
User Story
User StoryUser Story
User Story
 
User Story Mapping 101
User Story Mapping 101User Story Mapping 101
User Story Mapping 101
 
User Story Splitting
User Story SplittingUser Story Splitting
User Story Splitting
 
User Story Maps: Secrets for Better Backlogs and Planning
 User Story Maps: Secrets for Better Backlogs and Planning User Story Maps: Secrets for Better Backlogs and Planning
User Story Maps: Secrets for Better Backlogs and Planning
 
Introducing Agile User Stories
Introducing Agile User StoriesIntroducing Agile User Stories
Introducing Agile User Stories
 
User Story Splitting.pptx
User Story Splitting.pptxUser Story Splitting.pptx
User Story Splitting.pptx
 
User story and splitting workshop
User story and splitting workshopUser story and splitting workshop
User story and splitting workshop
 
Cheat Sheet: 8 ways to split your user stories
Cheat Sheet:  8 ways to split your user storiesCheat Sheet:  8 ways to split your user stories
Cheat Sheet: 8 ways to split your user stories
 
Vertical Slicing
Vertical SlicingVertical Slicing
Vertical Slicing
 
21 Story Splitting Patterns
21 Story Splitting Patterns21 Story Splitting Patterns
21 Story Splitting Patterns
 
Agile Story Writing
Agile Story WritingAgile Story Writing
Agile Story Writing
 

Similar to Agile and user story workshop Peter Saddington

CRASH & BURNdown
CRASH & BURNdownCRASH & BURNdown
CRASH & BURNdown
George Anghelache
 
How To Review The Sprints Efficiently
How To Review The Sprints EfficientlyHow To Review The Sprints Efficiently
How To Review The Sprints Efficiently
Lemi Orhan Ergin
 
CIO Leadership: What We Can Learn from History to Drive Success in Today's Cl...
CIO Leadership: What We Can Learn from History to Drive Success in Today's Cl...CIO Leadership: What We Can Learn from History to Drive Success in Today's Cl...
CIO Leadership: What We Can Learn from History to Drive Success in Today's Cl...
Jim Vaselopulos
 
Practical Guide to Scrum
Practical Guide to ScrumPractical Guide to Scrum
Practical Guide to Scrum
Pavel Dabrytski
 
The Role of a BA on a Scrum Team IIBA Presentation 2010
The Role of a BA on a Scrum Team IIBA Presentation 2010The Role of a BA on a Scrum Team IIBA Presentation 2010
The Role of a BA on a Scrum Team IIBA Presentation 2010
scrummasternz
 
Mark Foley Agile Methods And The Business Analystc
Mark Foley   Agile Methods And The Business AnalystcMark Foley   Agile Methods And The Business Analystc
Mark Foley Agile Methods And The Business Analystc
Mia Horrigan
 
Agile and Scrum Basics
Agile and Scrum BasicsAgile and Scrum Basics
Agile and Scrum Basics
Mazhar Khan
 
ACS an agile approach to optimising your digital strategy v4.1
ACS   an agile approach to optimising your digital strategy v4.1ACS   an agile approach to optimising your digital strategy v4.1
ACS an agile approach to optimising your digital strategy v4.1
Mia Horrigan
 
Seven elements of technical Agility - Gil Broza - Agile Israel 2013
Seven elements of technical Agility - Gil Broza - Agile Israel 2013Seven elements of technical Agility - Gil Broza - Agile Israel 2013
Seven elements of technical Agility - Gil Broza - Agile Israel 2013
AgileSparks
 
APN Auckland Event 9 - Scrum 101, Unleashing the Theory
APN Auckland Event 9 - Scrum 101, Unleashing the TheoryAPN Auckland Event 9 - Scrum 101, Unleashing the Theory
APN Auckland Event 9 - Scrum 101, Unleashing the Theory
Carolyn Sanders
 
The Role of the BA in Agile Software Development
The Role of the BA in Agile Software DevelopmentThe Role of the BA in Agile Software Development
The Role of the BA in Agile Software Development
John R. Durgin, CBAP, CSM, CSPO, MBA
 
Duet enterprise executive overview
Duet enterprise executive overviewDuet enterprise executive overview
Duet enterprise executive overview
Yi Guoyong
 
Salesforce CRM Cloud Governance Kickoff
Salesforce CRM Cloud Governance KickoffSalesforce CRM Cloud Governance Kickoff
Salesforce CRM Cloud Governance Kickoff
Chris Pearson, PMP
 
The Agile Readiness Assessment Tool Essay
The Agile Readiness Assessment Tool EssayThe Agile Readiness Assessment Tool Essay
The Agile Readiness Assessment Tool Essay
Heidi Owens
 
How to scale Agile With Scrum as the Foundational Framework
How to scale Agile With Scrum as the Foundational FrameworkHow to scale Agile With Scrum as the Foundational Framework
How to scale Agile With Scrum as the Foundational Framework
Hyperdrive Agile Leadership (powered by Bratton & Company)
 
Question to Understand (How to test an User Story #1)
Question to Understand (How to test an User Story #1)Question to Understand (How to test an User Story #1)
Question to Understand (How to test an User Story #1)
STAG Software Private Limited
 
The Whole Story of The User Story
The Whole Story of The User StoryThe Whole Story of The User Story
The Whole Story of The User Story
XPDays
 
Business Requirements: How to Create a Business Requirements Document (Free T...
Business Requirements: How to Create a Business Requirements Document (Free T...Business Requirements: How to Create a Business Requirements Document (Free T...
Business Requirements: How to Create a Business Requirements Document (Free T...
QuekelsBaro
 
Agile scrum induction
Agile scrum inductionAgile scrum induction
Agile scrum induction
Priyank Pathak
 
Lean Development Practices for Enterprise Agile
Lean Development Practices for Enterprise AgileLean Development Practices for Enterprise Agile
Lean Development Practices for Enterprise Agile
TechWell
 

Similar to Agile and user story workshop Peter Saddington (20)

CRASH & BURNdown
CRASH & BURNdownCRASH & BURNdown
CRASH & BURNdown
 
How To Review The Sprints Efficiently
How To Review The Sprints EfficientlyHow To Review The Sprints Efficiently
How To Review The Sprints Efficiently
 
CIO Leadership: What We Can Learn from History to Drive Success in Today's Cl...
CIO Leadership: What We Can Learn from History to Drive Success in Today's Cl...CIO Leadership: What We Can Learn from History to Drive Success in Today's Cl...
CIO Leadership: What We Can Learn from History to Drive Success in Today's Cl...
 
Practical Guide to Scrum
Practical Guide to ScrumPractical Guide to Scrum
Practical Guide to Scrum
 
The Role of a BA on a Scrum Team IIBA Presentation 2010
The Role of a BA on a Scrum Team IIBA Presentation 2010The Role of a BA on a Scrum Team IIBA Presentation 2010
The Role of a BA on a Scrum Team IIBA Presentation 2010
 
Mark Foley Agile Methods And The Business Analystc
Mark Foley   Agile Methods And The Business AnalystcMark Foley   Agile Methods And The Business Analystc
Mark Foley Agile Methods And The Business Analystc
 
Agile and Scrum Basics
Agile and Scrum BasicsAgile and Scrum Basics
Agile and Scrum Basics
 
ACS an agile approach to optimising your digital strategy v4.1
ACS   an agile approach to optimising your digital strategy v4.1ACS   an agile approach to optimising your digital strategy v4.1
ACS an agile approach to optimising your digital strategy v4.1
 
Seven elements of technical Agility - Gil Broza - Agile Israel 2013
Seven elements of technical Agility - Gil Broza - Agile Israel 2013Seven elements of technical Agility - Gil Broza - Agile Israel 2013
Seven elements of technical Agility - Gil Broza - Agile Israel 2013
 
APN Auckland Event 9 - Scrum 101, Unleashing the Theory
APN Auckland Event 9 - Scrum 101, Unleashing the TheoryAPN Auckland Event 9 - Scrum 101, Unleashing the Theory
APN Auckland Event 9 - Scrum 101, Unleashing the Theory
 
The Role of the BA in Agile Software Development
The Role of the BA in Agile Software DevelopmentThe Role of the BA in Agile Software Development
The Role of the BA in Agile Software Development
 
Duet enterprise executive overview
Duet enterprise executive overviewDuet enterprise executive overview
Duet enterprise executive overview
 
Salesforce CRM Cloud Governance Kickoff
Salesforce CRM Cloud Governance KickoffSalesforce CRM Cloud Governance Kickoff
Salesforce CRM Cloud Governance Kickoff
 
The Agile Readiness Assessment Tool Essay
The Agile Readiness Assessment Tool EssayThe Agile Readiness Assessment Tool Essay
The Agile Readiness Assessment Tool Essay
 
How to scale Agile With Scrum as the Foundational Framework
How to scale Agile With Scrum as the Foundational FrameworkHow to scale Agile With Scrum as the Foundational Framework
How to scale Agile With Scrum as the Foundational Framework
 
Question to Understand (How to test an User Story #1)
Question to Understand (How to test an User Story #1)Question to Understand (How to test an User Story #1)
Question to Understand (How to test an User Story #1)
 
The Whole Story of The User Story
The Whole Story of The User StoryThe Whole Story of The User Story
The Whole Story of The User Story
 
Business Requirements: How to Create a Business Requirements Document (Free T...
Business Requirements: How to Create a Business Requirements Document (Free T...Business Requirements: How to Create a Business Requirements Document (Free T...
Business Requirements: How to Create a Business Requirements Document (Free T...
 
Agile scrum induction
Agile scrum inductionAgile scrum induction
Agile scrum induction
 
Lean Development Practices for Enterprise Agile
Lean Development Practices for Enterprise AgileLean Development Practices for Enterprise Agile
Lean Development Practices for Enterprise Agile
 

Recently uploaded

21stcenturyskillsframeworkfinalpresentation2-240509214747-71edb7ee.pdf
21stcenturyskillsframeworkfinalpresentation2-240509214747-71edb7ee.pdf21stcenturyskillsframeworkfinalpresentation2-240509214747-71edb7ee.pdf
21stcenturyskillsframeworkfinalpresentation2-240509214747-71edb7ee.pdf
emmanuelpulido003
 
Mandated reporting powerpoint to help with understanding your role
Mandated reporting powerpoint to help with understanding your roleMandated reporting powerpoint to help with understanding your role
Mandated reporting powerpoint to help with understanding your role
khidalgo2
 
Cracking the Customer Experience Code.pptx
Cracking the Customer Experience Code.pptxCracking the Customer Experience Code.pptx
Cracking the Customer Experience Code.pptx
Workforce Group
 
TALENT ACQUISITION AND MANAGEMENT LECTURE 5
TALENT ACQUISITION AND MANAGEMENT LECTURE 5TALENT ACQUISITION AND MANAGEMENT LECTURE 5
TALENT ACQUISITION AND MANAGEMENT LECTURE 5
projectseasy
 
Managing Customer & User Experience of Customers
Managing Customer & User Experience of CustomersManaging Customer & User Experience of Customers
Managing Customer & User Experience of Customers
SalmanTahir60
 
Anton Grutzmache- Ominisient: The Data Revolution in Banking: From Scoring Cr...
Anton Grutzmache- Ominisient: The Data Revolution in Banking: From Scoring Cr...Anton Grutzmache- Ominisient: The Data Revolution in Banking: From Scoring Cr...
Anton Grutzmache- Ominisient: The Data Revolution in Banking: From Scoring Cr...
itnewsafrica
 
Connected Small Boat Protection Solution | July 2024
Connected Small Boat Protection Solution | July  2024Connected Small Boat Protection Solution | July  2024
Connected Small Boat Protection Solution | July 2024
Hector Del Castillo, CPM, CPMM
 
PAWFESSIONAL ELVA MAX.pdfAAAAAAAAAAAAAAAAAAA
PAWFESSIONAL ELVA MAX.pdfAAAAAAAAAAAAAAAAAAAPAWFESSIONAL ELVA MAX.pdfAAAAAAAAAAAAAAAAAAA
PAWFESSIONAL ELVA MAX.pdfAAAAAAAAAAAAAAAAAAA
lawrenceads01
 
Staffan Canback - The 18 Rays of Project Management
Staffan Canback - The 18 Rays of Project ManagementStaffan Canback - The 18 Rays of Project Management
Staffan Canback - The 18 Rays of Project Management
Tellusant, Inc.
 
WAM Corporate Presentation July 2024.pdf
WAM Corporate Presentation July 2024.pdfWAM Corporate Presentation July 2024.pdf
WAM Corporate Presentation July 2024.pdf
Western Alaska Minerals Corp.
 
Case study on Indian Ecommerce logistics
Case study on Indian Ecommerce logisticsCase study on Indian Ecommerce logistics
Case study on Indian Ecommerce logistics
UnheardShayari
 
brojjeddah Home Services Company in Saudi Arabia
brojjeddah Home Services Company in Saudi Arabiabrojjeddah Home Services Company in Saudi Arabia
brojjeddah Home Services Company in Saudi Arabia
brojjeddah
 
شركات إبراهيم العرجاني: لدعم الاقتصاد المصري
شركات إبراهيم العرجاني: لدعم الاقتصاد المصريشركات إبراهيم العرجاني: لدعم الاقتصاد المصري
شركات إبراهيم العرجاني: لدعم الاقتصاد المصري
إبراهيم العرجاني
 
Top Digital Marketing Strategy in 2024.pdf
Top Digital Marketing Strategy in 2024.pdfTop Digital Marketing Strategy in 2024.pdf
Top Digital Marketing Strategy in 2024.pdf
Top IT Marketing
 
1234567891011121314151617181920212223242
12345678910111213141516171819202122232421234567891011121314151617181920212223242
1234567891011121314151617181920212223242
fauzanal343
 
MEA Union Budget 2024-25 Final Presentation
MEA Union Budget 2024-25 Final PresentationMEA Union Budget 2024-25 Final Presentation
MEA Union Budget 2024-25 Final Presentation
PhysicsUtu
 
BBA Final SML 501 INTERNATIONAL BUSINESS .pdf
BBA Final SML 501 INTERNATIONAL BUSINESS .pdfBBA Final SML 501 INTERNATIONAL BUSINESS .pdf
BBA Final SML 501 INTERNATIONAL BUSINESS .pdf
mcdopex6
 
Pricing sophistication - auto insurance telematics
Pricing sophistication - auto insurance telematicsPricing sophistication - auto insurance telematics
Pricing sophistication - auto insurance telematics
Matteo Carbone
 
United Kingdom's Real Estate Mogul: Newman George Leech's Impact on the Swiss...
United Kingdom's Real Estate Mogul: Newman George Leech's Impact on the Swiss...United Kingdom's Real Estate Mogul: Newman George Leech's Impact on the Swiss...
United Kingdom's Real Estate Mogul: Newman George Leech's Impact on the Swiss...
Newman George Leech
 
Test Bank For Principles Of Cost Accounting, 17th Edition Edward J. Vander...
Test Bank For Principles Of Cost Accounting, 	  17th Edition Edward J. Vander...Test Bank For Principles Of Cost Accounting, 	  17th Edition Edward J. Vander...
Test Bank For Principles Of Cost Accounting, 17th Edition Edward J. Vander...
kevinkariuki227
 

Recently uploaded (20)

21stcenturyskillsframeworkfinalpresentation2-240509214747-71edb7ee.pdf
21stcenturyskillsframeworkfinalpresentation2-240509214747-71edb7ee.pdf21stcenturyskillsframeworkfinalpresentation2-240509214747-71edb7ee.pdf
21stcenturyskillsframeworkfinalpresentation2-240509214747-71edb7ee.pdf
 
Mandated reporting powerpoint to help with understanding your role
Mandated reporting powerpoint to help with understanding your roleMandated reporting powerpoint to help with understanding your role
Mandated reporting powerpoint to help with understanding your role
 
Cracking the Customer Experience Code.pptx
Cracking the Customer Experience Code.pptxCracking the Customer Experience Code.pptx
Cracking the Customer Experience Code.pptx
 
TALENT ACQUISITION AND MANAGEMENT LECTURE 5
TALENT ACQUISITION AND MANAGEMENT LECTURE 5TALENT ACQUISITION AND MANAGEMENT LECTURE 5
TALENT ACQUISITION AND MANAGEMENT LECTURE 5
 
Managing Customer & User Experience of Customers
Managing Customer & User Experience of CustomersManaging Customer & User Experience of Customers
Managing Customer & User Experience of Customers
 
Anton Grutzmache- Ominisient: The Data Revolution in Banking: From Scoring Cr...
Anton Grutzmache- Ominisient: The Data Revolution in Banking: From Scoring Cr...Anton Grutzmache- Ominisient: The Data Revolution in Banking: From Scoring Cr...
Anton Grutzmache- Ominisient: The Data Revolution in Banking: From Scoring Cr...
 
Connected Small Boat Protection Solution | July 2024
Connected Small Boat Protection Solution | July  2024Connected Small Boat Protection Solution | July  2024
Connected Small Boat Protection Solution | July 2024
 
PAWFESSIONAL ELVA MAX.pdfAAAAAAAAAAAAAAAAAAA
PAWFESSIONAL ELVA MAX.pdfAAAAAAAAAAAAAAAAAAAPAWFESSIONAL ELVA MAX.pdfAAAAAAAAAAAAAAAAAAA
PAWFESSIONAL ELVA MAX.pdfAAAAAAAAAAAAAAAAAAA
 
Staffan Canback - The 18 Rays of Project Management
Staffan Canback - The 18 Rays of Project ManagementStaffan Canback - The 18 Rays of Project Management
Staffan Canback - The 18 Rays of Project Management
 
WAM Corporate Presentation July 2024.pdf
WAM Corporate Presentation July 2024.pdfWAM Corporate Presentation July 2024.pdf
WAM Corporate Presentation July 2024.pdf
 
Case study on Indian Ecommerce logistics
Case study on Indian Ecommerce logisticsCase study on Indian Ecommerce logistics
Case study on Indian Ecommerce logistics
 
brojjeddah Home Services Company in Saudi Arabia
brojjeddah Home Services Company in Saudi Arabiabrojjeddah Home Services Company in Saudi Arabia
brojjeddah Home Services Company in Saudi Arabia
 
شركات إبراهيم العرجاني: لدعم الاقتصاد المصري
شركات إبراهيم العرجاني: لدعم الاقتصاد المصريشركات إبراهيم العرجاني: لدعم الاقتصاد المصري
شركات إبراهيم العرجاني: لدعم الاقتصاد المصري
 
Top Digital Marketing Strategy in 2024.pdf
Top Digital Marketing Strategy in 2024.pdfTop Digital Marketing Strategy in 2024.pdf
Top Digital Marketing Strategy in 2024.pdf
 
1234567891011121314151617181920212223242
12345678910111213141516171819202122232421234567891011121314151617181920212223242
1234567891011121314151617181920212223242
 
MEA Union Budget 2024-25 Final Presentation
MEA Union Budget 2024-25 Final PresentationMEA Union Budget 2024-25 Final Presentation
MEA Union Budget 2024-25 Final Presentation
 
BBA Final SML 501 INTERNATIONAL BUSINESS .pdf
BBA Final SML 501 INTERNATIONAL BUSINESS .pdfBBA Final SML 501 INTERNATIONAL BUSINESS .pdf
BBA Final SML 501 INTERNATIONAL BUSINESS .pdf
 
Pricing sophistication - auto insurance telematics
Pricing sophistication - auto insurance telematicsPricing sophistication - auto insurance telematics
Pricing sophistication - auto insurance telematics
 
United Kingdom's Real Estate Mogul: Newman George Leech's Impact on the Swiss...
United Kingdom's Real Estate Mogul: Newman George Leech's Impact on the Swiss...United Kingdom's Real Estate Mogul: Newman George Leech's Impact on the Swiss...
United Kingdom's Real Estate Mogul: Newman George Leech's Impact on the Swiss...
 
Test Bank For Principles Of Cost Accounting, 17th Edition Edward J. Vander...
Test Bank For Principles Of Cost Accounting, 	  17th Edition Edward J. Vander...Test Bank For Principles Of Cost Accounting, 	  17th Edition Edward J. Vander...
Test Bank For Principles Of Cost Accounting, 17th Edition Edward J. Vander...
 

Agile and user story workshop Peter Saddington

  • 1. Agile with SCRUM Overview and User Stories Peter Saddington, CSM CSP Enterprise Agile Coach Executive Editor AgileScout.com @agilescout
  • 2. White Barrel LLC. © 2011 Peter Saddington Peter Saddington, CSP CSM Independent Enterprise Agile Coach Rally Software Agile Coach Executive Editor AgileScout.com Author – Scrum Pocket Guide [email_address] +1.404.669.6662 www.agilescout.com www.scrumpocketguide.com Twitter: @agilescout
  • 3. Before we begin… A Standup! Let’s take a moment to introduce ourselves. What’s your name & project you’re working on? What is your level of experience with Agile? What do you hope to learn in this workshop? Write questions on Sticky notes as they occur to you and affix them to our Learning Backlog . White Barrel LLC. © 2011 Peter Saddington
  • 4. Free Swag = #win! White Barrel LLC. © 2010 Peter Saddington www.scrumpocketguide.com
  • 5. Agile Manifesto Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan White Barrel LLC. © 2011 Peter Saddington www.agilemanifesto.org
  • 6. Distilled Principles of Agile Manifesto Priority is to satisfy the customer Deliver working software frequently Business and development work together Working software is primary measure of success The team regularly reflects on work Build projects around motivated people White Barrel LLC. © 2011 Peter Saddington
  • 7. Process Frameworks Waterfall White Barrel LLC. © 2011 Peter Saddington
  • 8. Process Frameworks Iterative White Barrel LLC. © 2011 Peter Saddington
  • 9. Process Frameworks Agile White Barrel LLC. © 2011 Peter Saddington
  • 10. Agile vs Scrum vs Other Frameworks Agile is a mindset, there are several ways to implement Agile: XP – Extreme Programming DSDM – Dynamic Systems Development Method Scrum – lightweight team centric processes Lean – Manufacturing processes applied to software FDD – Feature centric processes White Barrel LLC. © 2011 Peter Saddington
  • 11. Scrum Scrum is not an acronym, but a strategy in the game of rugby for getting an out-of-play ball back into play. White Barrel LLC. © 2011 Peter Saddington
  • 12. Exercise – Batch vs Flow Four volunteers, please! Round 1 Each person flips all pennies When done with entire batch, pass to next person Round 2 Each person flip one penny and pass to next person Keep flipping and passing until done Round 3 Each table creates their own rules to maximize penny flow/throughput in least amount of time White Barrel LLC. © 2011 Peter Saddington
  • 13. Scrum Rules Scrum is a set of rules, procedures, and practices Improve the development environment Reduce organizational overheads Ensure iterative deliverables match user requirements White Barrel LLC. © 2011 Peter Saddington
  • 14. Scrum Approach Work together as a whole team Focus on business priorities Time box short sprints and releases Commit and deliver value incrementally White Barrel LLC. © 2011 Peter Saddington
  • 15. The Chicken and the Pig – A Story: Bacon and Egg Restaurant Chickens involved… Pigs are committed! White Barrel LLC. © 2011 Peter Saddington
  • 16. How It All Starts A Scrum project starts with a vision of the system or product to be developed The vision might be vague at first… Perhaps stated in market terms rather than system terms… But it will become clearer as the project moves forward White Barrel LLC. © 2011 Peter Saddington
  • 17. Scrum Roles Product Owner The single customer voice who establishes the vision, prioritizes the work and defines success criteria ScrumMaster The situational leader who empowers the team, facilitates the process, and removes impediments Cross-functional team The people who deliver the customer value White Barrel LLC. © 2011 Peter Saddington
  • 18. Scrum Meetings Daily Scrum Sprint Planning Meeting Sprint Review Meeting* Demo Sprint Retrospective White Barrel LLC. © 2011 Peter Saddington
  • 19. Scrum Artifacts User Stories Product Backlog List of functional and non-functional requirements Sprint Backlog Prioritized list of stories for a given sprint Sprint Burndown Chart A chart showing completion of stories over time Definition of done White Barrel LLC. © 2011 Peter Saddington
  • 20. The Bottom Line Scrum is: Doing the simplest thing possible Getting a team what it needs and getting out of their way Removing any obstacle that is preventing a team from being productive and efficient White Barrel LLC. © 2011 Peter Saddington
  • 21. Final Thoughts The core of Agile is the team Focus on the priorities first (most valuable) Communication Document throughout the process instead of all up front Review, review, review Define the “done.” White Barrel LLC. © 2011 Peter Saddington
  • 22. User Stories – Better Practices A Quick Guide to Story Creation in Scrum Peter Saddington CSM, CSP Agile Scrum Coach
  • 23. A Worldview White Barrel LLC © 2010 Peter Saddington
  • 24. Roadmap White Barrel LLC © 2010 Peter Saddington
  • 25. Why Not Requirements Documents? Complete specifications: Assume everything is knowable in advance Are time-consuming to write and tedious to read Treat learning as a “Change of Scope” Don’t lend themselves to iterative, incremental delivery process White Barrel LLC © 2010 Peter Saddington
  • 26. User Stories are a Conversation User stories are: User or customer need Product description Used for planning A conversation piece White Barrel LLC © 2010 Peter Saddington
  • 27. User Stories Facilitate Conversation User* – How do I describe what I want? Stakeholder – What do I need in my product to be successful? PM – How do I track and schedule this work? BA – What are the details of this feature? UX – How do I understand the users needs? Developer – What are the details of the tasks I need to work on today? QA – How do I validate this completed work? White Barrel LLC © 2010 Peter Saddington Adapted from Jeff Patton www.AgileProductDesign.com
  • 28. Easy to understand – Makes sense to the reader A (software/system) requirement One or two sentences with value to the customer Written by the Customer – PO or BA Refined by Development – Tasks and Technical Negotiable – Conversation token Small and estimable – Small enough to estimate Testable – Should have acceptance criteria Becomes more detailed over time – Iteration Planning White Barrel LLC © 2010 Peter Saddington A User Story Is
  • 29. White Barrel LLC © 2010 Peter Saddington User Story Process Step #1 Step #2 Step #3
  • 30. Define the user personas! What different types of customers/consumers interact with the system? What are their roles? White Barrel LLC © 2010 Peter Saddington Step #1 - Where do we start?
  • 31. User Roles Various types of user personas Role Modeling Brain storming Organizing Consolidating Refining Extreme Characters? White Barrel LLC © 2010 Peter Saddington User Role Modeling
  • 32. Scenario : You need to create a simple login and preferences mechanism for your corporate Twitter account Who are your users of this system? What are their roles? White Barrel LLC © 2010 Peter Saddington Exercise - Defining the Personas
  • 33. White Barrel LLC © 2010 Peter Saddington Persona Definition Documentation?
  • 34. Roadmap White Barrel LLC © 2010 Peter Saddington
  • 35. Story Creation - Guidelines Stakeholders write user stories Remember non-functional requirements Indicate the estimated size Indicate the priority Include a unique identifier (if applicable) Go into a product backlog The product backlog is prioritized by value – Highest to lowest White Barrel LLC © 2010 Peter Saddington
  • 36. Non-Functional Requirements Non-functional requirements should often be considered “constraints” on a system Can include: Performance Quality Accuracy Portability Reusability Maintainability Interoperability Capacity White Barrel LLC © 2010 Peter Saddington Adapted from Mike Cohn www.mountaingoatsoftware.com
  • 37. INVEST Model I ndependent – One user story should be independent of another (as much as possible). Dependencies between stories make planning, prioritization, and estimation much more difficult. N egotiable – Details of the story can be worked out during an Iteration planning meeting. A story with too much detail can limit conversations (at times). V aluable – Value to the customer. E stimable – There needs to be enough detail for the developers to estimate a user story to allow prioritization and planning of the story. S mall – A good story should be small in effort, typically no more than 2-3 person weeks of effort (smaller is better)! T estable – User stories should be testable with certain acceptance criteria. Saying something like “software should be easy to use” is not helpful. White Barrel LLC © 2010 Peter Saddington Bill Wake’s INVEST Model
  • 38. Ron Jeffries 3 C’s Card – Stories written on note cards with annotations as needed (estimates, notes, etc) Conversation – Details behind story come out through conversations with the Product Owner Confirmation – Acceptance tests confirm the story was coded correctly White Barrel LLC © 2010 Peter Saddington
  • 39. Four Main Components of a Story ( Given ( AS A ) ) – “As a business owner…” / “Given a new list…” ( When ( I WANT ) ) – “I’d like the ability to…” / “We need a function to…” / “When a customer clicks on…” / “When a dropdown opens…” ( Then ( SO THAT ) ) – “So that I can…” / “So that the customer can…” / “Then the customer should see…” / “Then the dropdown list should…” ( Acceptance Criteria ) – Verifiable and testable criteria that can be tested based on THEN clause. Or Simply: “As a <user type>, I want to <function> so that I can <business value> White Barrel LLC © 2010 Peter Saddington
  • 40. 1. Given ( Given ( AS A ) ) – “As a business owner…” / “Given a new list…” We want users to be tangible with needs Build out “Personas” or “User Roles” – Standard user definitions (Sacred – Added with purpose) Avoid generic terms White Barrel LLC © 2010 Peter Saddington
  • 41. 2. When ( When ( I WANT ) ) – “I’d like the ability to…” / “We need a function to…” / “When a customer clicks on…” / “When a dropdown opens…” This is the meat and potatoes of the story This is where you describe the functions White Barrel LLC © 2010 Peter Saddington
  • 42. 3. Then ( Then ( SO THAT ) ) – “So that I can…” / “So that the customer can…” / “Then the customer should see…” / “Then the dropdown list should…” This is to show the intrinsic value of the story The value is to the persona, user, or author White Barrel LLC © 2010 Peter Saddington
  • 43. 4. Acceptance Criteria ( Acceptance Criteria ) – Verifiable and testable criteria that can be tested based on THEN clause. These are essentially tests – Conditions of satisfaction Example: As a user, I can cancel a reservation. Verify that a premium member can cancel Verify that a email confirmation is sent Verify that the hotel is notified of any cancelation These acceptance criteria can become developer tasks White Barrel LLC © 2010 Peter Saddington
  • 44. 4a. Acceptance Stories ( Acceptance Stories ) – Verifiable and testable criteria written in acceptance test form. Scenario 1: TITLE GIVEN [context] And [some more context] When [event] Then [outcome] And [another outcome] White Barrel LLC © 2010 Peter Saddington
  • 45. 4b. Acceptance Confirmation ( Acceptance Confirmation ) – Verifiable and testable criteria written in “Success” and “Failure” terms Success – valid user logged in “ Remember my user name” selected – store cookie / automatic login next time “ Remember my user name” not selected – force login next time Failure – display message: “ Email address in wrong format” “ Incorrect password, please try again” “ Service unavailable, please try again” Etc. White Barrel LLC © 2010 Peter Saddington
  • 46. Exercise – 99 Balloons Let’s form some teams! Round 1 Recreate my balloon with: 2 round eyes, a triangle nose, and a semi-circle mouth 2 minutes! Go! Round 2 How can you improve for the next iteration? Round 3 How did you change how you worked this time around? White Barrel LLC. © 2011 Peter Saddington
  • 47. User Interviews Select right interviewees Ask open-ended, context-free questions Questionnaires Larger population of users When you need specific answers to questions Observation Best for in-house developments Story writing workshops White Barrel LLC © 2010 Peter Saddington Step #2 – Gathering User Stories
  • 48. Scenario : You need to create a simple login and preferences mechanism for your corporate Twitter account We’ve determined our users… Let’s refine the set of user stories White Barrel LLC © 2010 Peter Saddington Exercise – Refine the User Stories
  • 49. Roadmap White Barrel LLC © 2010 Peter Saddington
  • 50. Product Backlog to Release Backlog A prioritized list of features for the given product Stories are implemented based on their priority The TOP priority Features are put into iterations first Changes to the iterations are OK After stories are built they go into a release backlog White Barrel LLC. © 2010 Peter Saddington
  • 51. Prioritization Factors to Consider Financial value of features Costs of implementation Amount of risk removed / added Training on new features PO should be enabled White Barrel LLC. © 2010 Peter Saddington
  • 52. MoSCoW Method M – MUST have (Critical for success) S – SHOULD have if possible (If not time critical) C – COULD have if it does not affect anything else (Include if little development cost) W – WON’T have this time, but WOULD like in future White Barrel LLC © 2010 Peter Saddington MoSCoW method - Dai Clegg of Oracle UK for DSDM
  • 53. M & S of MoSCoW M – MUST have (Critical for success) Essential - key stakeholders needs will not be satisfied if this requirement is not delivered and the timebox will be considered to have failed S – SHOULD have if possible (If not time critical) Important - but if not delivered within the current timebox, there is an acceptable workaround until it is delivered during the next sprint White Barrel LLC © 2010 Peter Saddington
  • 54. C & W of MoSCoW C – COULD have if it does not affect anything else (Include if little development cost) “ Nice to have” – this is estimated to be possible to complete in the timebox but will be de-scoped if an underestimation has occured W – WON’T have this time, but WOULD like in future Will not be delivered within the timebox White Barrel LLC © 2010 Peter Saddington
  • 55. Kano’s Model of Quality Objective and Subjective Quality Must-haves – Same as “M” in MoSCoW One-dimensional – “The more of this I get, the better.” Delighters – Great to haves White Barrel LLC © 2010 Peter Saddington Noriaki Kano – Theory of Product Development
  • 56. Kano’s Model - Example In Agile – Objective quality is non-negotiable Subjective quality – Perception of quality To accurately assess subjective quality, the Product Owner MUST know the customers (primary users) One user’s “delighter” may leave others apathetic One user’s “must have” is useless to others White Barrel LLC © 2010 Peter Saddington Jeff Paton – www.Agileproductdesign.com
  • 57. Prioritization Sliders White Barrel LLC. © 2010 Peter Saddington
  • 58. Manage the backlog by: Sorting stories by user persona Sorting stories by highest priority (value) Review stories for completeness Asking the 4 “WHYs” for business value Why do you want…? [As a] Customer Service Representative [I want] to have a button [So that] I can go to the next screen… White Barrel LLC © 2010 Peter Saddington Step #3 – A.C. and Backlog Priority
  • 59. Scenario : You need to create a simple login and preferences mechanism for your corporate Twitter account We’ve determined our users… We’ve refined the set of user stories Let’s put A.C. and priority White Barrel LLC © 2010 Peter Saddington Exercise – Stories to Backlog
  • 60. Roadmap White Barrel LLC © 2010 Peter Saddington
  • 61. Themes to Tasks White Barrel LLC © 2010 Peter Saddington
  • 62. Tasks Warm Up Exercise What are all the things you did to get ready to be at work today? Starting from the moment you woke up to arriving here. Take a sheet of paper and write them down! White Barrel LLC © 2010 Peter Saddington
  • 63. Tasks vs Tools Exercise Share with the group some example lists What are common themes and tasks? What was different? White Barrel LLC © 2010 Peter Saddington
  • 64. Goals, Tasks, Tools White Barrel LLC © 2010 Peter Saddington
  • 65. User Stories are Tasks or Tools White Barrel LLC © 2010 Peter Saddington
  • 66. Stories Satisfy User NEEDS First! White Barrel LLC © 2010 Peter Saddington
  • 67. Start with specific personas Write closed stories first Write stories collaboratively White Barrel LLC © 2010 Peter Saddington Simple Guidelines for Good Stories
  • 68. Exercise – Creating at a Story Ta ke a current feature your team is aware of Each team member writes the story Share Discuss – Implications / Constraints / Missed AC Review White Barrel LLC © 2010 Peter Saddington
  • 69. Roadmap White Barrel LLC © 2010 Peter Saddington
  • 70. Epic User Stories Causes for Story Size Stories cover too much information Story writers do not have the needed domain knowledge Stories have uncertainty due to dependence on new technology Story writers cannot articulate exactly what they want White Barrel LLC © 2010 Peter Saddington
  • 71. Breaking Up Epics Split – Slice stories up into different scenarios Spike – Too many unknowns? Time-box a spike and take a deep dive into the technology or domain Stub – Part of a story known and part unknown. Fake it with a stub! Work on the known part up till the unknown. Time box – The PO knows they need something, but until they get it, not sure if it’s right White Barrel LLC © 2010 Peter Saddington
  • 72. Splitting for Value - Three Rules When breaking down epics, remember: Split stories for value – No value? Hard to prioritize Split a story that gets you more equally sized small stories Split an epic that lets you deprioritize or throw away a story White Barrel LLC © 2010 Peter Saddington
  • 73. Exercise – Breaking Up Epics Let’s take an example from our existing backlog White Barrel LLC © 2010 Peter Saddington
  • 74. Suggestions for Splitting Up Epics Handle empty scenarios and core functions first Happy path, then alternate flows / exceptions Single option, then add additional options Simple (or no) UI, then add bells / whistles Transient case (no memory between sessions) before persistence Static elements, then dynamic based on content User specified, then more automation White Barrel LLC © 2010 Peter Saddington
  • 75. Roadmap White Barrel LLC © 2010 Peter Saddington
  • 76. Notes on Bug or Issue Tracking Steps to Reproduce / Recreate the Bug Actual Results Expected Results Any other details as appropriate White Barrel LLC © 2010 Peter Saddington
  • 77. Exercise – Baseline Story Estimation Different Stories in different sizes (1,2,3,5,8…) What was the estimated size? What were the complexities of that story? Does this story need a re-write? What was missed? Complete for sizes White Barrel LLC © 2010 Peter Saddington
  • 78. Questions? White Barrel LLC © 2010 Peter Saddington

Editor's Notes

  1. Stakeholders write user stories – User stories are supposed to be simple, with simple description and acceptance criteria. Use business language. Remember non-functional requirements – Stories can also include a variety of requirement types. Indicate the estimated size – A story should include an estimate effort. The developers currently do this during the iteration planning meetings and can include technical detail. Indicate the priority – We prioritize through the placement of the story. Include a unique identifier – We should include an identifier so we can trace back stories to their original requirements documents and/or project request forms.
  2. Stakeholders write user stories – User stories are supposed to be simple, with simple description and acceptance criteria. Use business language. Remember non-functional requirements – Stories can also include a variety of requirement types. Indicate the estimated size – A story should include an estimate effort. The developers currently do this during the iteration planning meetings and can include technical detail. Indicate the priority – We prioritize through the placement of the story. Include a unique identifier – We should include an identifier so we can trace back stories to their original requirements documents and/or project request forms.
  3. Stakeholders write user stories – User stories are supposed to be simple, with simple description and acceptance criteria. Use business language. Remember non-functional requirements – Stories can also include a variety of requirement types. Indicate the estimated size – A story should include an estimate effort. The developers currently do this during the iteration planning meetings and can include technical detail. Indicate the priority – We prioritize through the placement of the story. Include a unique identifier – We should include an identifier so we can trace back stories to their original requirements documents and/or project request forms.
  4. Stakeholders write user stories – User stories are supposed to be simple, with simple description and acceptance criteria. Use business language. Remember non-functional requirements – Stories can also include a variety of requirement types. Mike Cohn often has said that non-functional requirements should be considered “constraints” on the system or development team. Indicate the estimated size – A story should include an estimate effort. The developers currently do this during the iteration planning meetings and can include technical detail. Indicate the priority – We prioritize through the placement of the story. Include a unique identifier – We should include an identifier so we can trace back stories to their original requirements documents and/or project request forms.
  5. Stakeholders write user stories – User stories are supposed to be simple, with simple description and acceptance criteria. Use business language. Remember non-functional requirements – Stories can also include a variety of requirement types. Mike Cohn often has said that non-functional requirements should be considered “constraints” on the system or development team. Indicate the estimated size – A story should include an estimate effort. The developers currently do this during the iteration planning meetings and can include technical detail. Indicate the priority – We prioritize through the placement of the story. Include a unique identifier – We should include an identifier so we can trace back stories to their original requirements documents and/or project request forms.
  6. Conversation – if requirements are written down, what happens? [the PO will get what he wants?] OR [The PO will get what is written?] – Words are imprecise. The story we write on cards is less important than the conversations we have.
  7. Show teams balloon. Acceptance criteria and requirements – I will provide. Built test harnesses, templates, requirement specs Defining acceptance criteria is not the same as writing tests or test cases. Automating acceptance tests can be very helpful The investment in creating better requirements and acceptance criteria is worthwhile and has high return!
  8. There are many different ways of gathering user stories. Here are some of them
  9. To have a better understanding of prioritization we must look at the MoSCoW method through the lens of Kano’s model of quality Objective quality is the conformance to requirements Subjective Quality pertains to the satisfaction of users
  10. To have a better understanding of prioritization we must look at the MoSCoW method through the lens of Kano’s model of quality Objective quality is the conformance to requirements Subjective Quality pertains to the satisfaction of users
  11. Why do you want a button? // To go to the next screen Why do you want to go to the next screen? // So I can skip ahead to other parts of the questionnaire Why do you want to skip ahead? // So I can save time on non-required parts… Why do you want to save time on non-required parts? // So I can help more customers in less time.