Agile and user story workshop Peter Saddington
•Download as PPT, PDF•
90 likes•35,726 views
The document provides an overview of Agile and Scrum frameworks and processes. It discusses key Scrum roles like Product Owner and Scrum Master. It also covers Scrum artifacts like user stories, product and sprint backlogs. The document emphasizes that user stories should be short, independent, negotiable, valuable, estimable, small, and testable (INVEST criteria). It provides examples of proper user story structure and components.
![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](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Agile and user story workshop Peter Saddington
Similar to Agile and user story workshop Peter Saddington (20)
Recently uploaded
Recently uploaded (20)
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
- 4. Free Swag = #win! White Barrel LLC. © 2010 Peter Saddington www.scrumpocketguide.com
- 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
- 29. White Barrel LLC © 2010 Peter Saddington User Story Process Step #1 Step #2 Step #3
- 33. White Barrel LLC © 2010 Peter Saddington Persona Definition Documentation?
- 34. Roadmap White Barrel LLC © 2010 Peter Saddington
- 49. Roadmap White Barrel LLC © 2010 Peter Saddington
- 57. Prioritization Sliders White Barrel LLC. © 2010 Peter Saddington
- 60. Roadmap White Barrel LLC © 2010 Peter Saddington
- 61. Themes to Tasks 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
- 69. Roadmap White Barrel LLC © 2010 Peter Saddington
- 75. Roadmap White Barrel LLC © 2010 Peter Saddington
- 78. Questions? White Barrel LLC © 2010 Peter Saddington
Editor's Notes
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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!
- There are many different ways of gathering user stories. Here are some of them
- 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
- 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
- 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.