Agenda for Creating and Splitting User Stories
•Transferir como PPTX, PDF•
2 gostaram•1,091 visualizações
This is a session I prepared for the R&D team at Global 360.
Recomendados
Recomendados
Mais conteúdo relacionado
Destaque
Destaque (8)
Semelhante a Agenda for Creating and Splitting User Stories
Semelhante a Agenda for Creating and Splitting User Stories (20)
Último
Último (20)
Agenda for Creating and Splitting User Stories
- 2. Agenda Why stories? What stories are? What stories are not? How to create a story? How to split a story? When to split a story? Story smells
- 3. Why stories? Verbal communication
- 4. Why stories? Verbal communication As an Administrator I want the system to constantly make sure it is healthy so that I don't have to worry about it
- 5. Why stories? Verbal communication As an Administrator I can use a watchdog service so that I know when the system stopped working
- 7. Why stories? Comprehensible As a Developer I want a standard exception class and conventions for use throughout all the server source code so that I don't have to reinvent the wheel
- 8. Why stories? Comprehensible As a participant I want to know what to do in the event of an application malfunction So that I can continue working
- 9. Why stories? Comprehensible As a participant I want to know what to do in the event of an application malfunction so that I can continue working As a Developer I want a standard exception class and conventions for use throughout all the server source code so that I don't have to reinvent the wheel
- 10. Why stories? Right size for planning
- 11. Why stories? Great for Iterative development
- 12. Why stories? Defer detail
- 13. Why stories? Defer detail Release planning – no details Iteration planning – increasing detail Iteration – maximum detail
- 14. Why stories? Tacit knowledge
- 15. Why stories? Review 1. Do talk stories, don’t write novels 2. Write for dummies 3. Change stories as you need 4. Enough detail to move along
- 17. What stories are? A reminder to talk A phrase or two that act as a reminder to hold the conversation
- 18. What stories are? A reminder to talk Notes about issues resolved during the conversation
- 19. What stories are? Common format As a …. Kid I want …. to carry my bucket in the neighborhood So that …. I can get lots of candies
- 20. What stories are? Front side Halloween fun As a Kid I want to carry my bucket in the neighborhood So that I can get lots of candies Customer: Lafayette Police Department
- 21. What stories are? Flip side/Acceptance • Put all crooks in jail • Have at least 10 patrol cars on the streets • Write a safety brochure • Distribute the safety brochure • Make sure officers’ kids have enough candy
- 22. What stories are? Review 1. Reminder of a conversation 2. Try, make a mistake, and try again 3. If it’s bigger than a (large) PostIt its too big 4. Where’s the real Value, Value, Value
- 23. What stories are not? requirements
- 24. What stories are not? requirements 1. The product shall have gasoline engine 2. The product shall have four wheels a) The product shall have rubber tire for each wheel 3. The product shall have steering wheel 4. The product shall have steel body WHAT IS THE PRODUCT?
- 25. What stories are not? requirements SPEED GRASS MOWER
- 26. What stories are not? requirements As a busy dad I can mow the lawn easy and quickly so that I have more time for my family
- 27. What stories are not? too specialized As a Builder I want each solution to contain an archetype for folders in that solution so that I can provide users with built-in foldering services
- 28. What stories are not? too specialized As a doc-check I want to be able to process New York three times faster so that I can meet TPC
- 29. What stories are not? use cases Use Cases Stories Number of players Multiple single Alternate routes yes no Scope Large Large/Epic and Small Longevity Permanent Changing Paper trail Extensively documented Short note discarded after completed
- 30. What stories are not? use cases Example: Builder use cases
- 31. What stories are not? Interaction design scenarios Heroflows Stories Number of actors One or more single Level of details Deep Enough to estimate Scope Multiple stories Single story Longevity Permanent Changing Paper trail Extensively documented Short note discarded after completed
- 32. What stories are not? Interaction design scenarios Example: Creating a new library & content type
- 33. What stories are not? Review Interaction design scenario Use Case Complete description of Story & Acceptance Criteria Story : As a participant… Acceptance : • . . . • . . . • . . .
- 34. What stories are not? Review 1. A story is a tool to capture requirements on the move, not the requirement itself 2. Use cases and heroflows are not stories, but can be a good source for stories 3. All players should understand the story
- 35. How to create a story? The perfect story Negotiable Valuable to Purchasers and Users Estimable Small Testable
- 36. How to create a story? Team effort • Create a Product Owner (or Customer) Team – Real user (rarely) – Product manager – Interaction designer – Behavioral designer or non technical specialist – ------------------------------------- – Sales engineer – Support engineer – Developer – Tester
- 37. How to create a story? Team effort • Conduct a story writing workshop – Time boxed – Defer details
- 38. How to create a story? Roles and persona
- 39. How to create a story? Roles and persona • For each action that the role can do draw a line to a new box, label the box and write a story Create Folder Create Content Type Configure Storage
- 40. How to create a story? Roles and persona • Let’s try it!
- 41. How to create a story? Create prototypes • low fidelity • throw them away once the session is completed
- 42. How to create a story? Design
- 43. How to create a story? Review 1. Start with defined roles and persona 2. Conduct a story writing workshop 3. Stories are a team effort 4. Early prototypes are communication tool, not a design artifact
- 44. How to split a story? Start large, end with right size • Start with broader strokes and epics • Split in smaller stories close to release and iteration
- 45. How to split a story? Compound story Low Complexity A lot of work
- 46. How to split a story? Cut the cake
- 47. How to split a story? Split on data boundaries • First Name • Last Name • Address 1 • Address 2 • City • State • ZIP Story A Story B Story A
- 48. How to split a story? Complex story Research/design story – short – time boxed Implementation story - plan for another iteration
- 49. How to split a story? Split on priority High priority parts go up in the backlog Low priority parts get in separate stories
- 50. When to split a story? Release planning some Iteration planning most End of iteration some
- 51. How to create a story? Defer detail • 508 Compliance • Issues?
- 52. How to create a story? Defer detail • As a participant with disabilities I can use the document management system, so that my disability does not affect my productivity
- 53. How to create a story? Defer detail • As a participant I can use a text equivalent for every non-text element on the screen so that if I am vision impaired, I can work with the system
- 54. How to create a story? Defer detail • As a participant I can use a text equivalent for every toolbar icons on the screen so that if I am vision impaired, I can work with the system • As a participant I can use a text equivalent for every dialog box buttons on the screen so that if I am vision impaired, I can work with the system
- 55. How and When to split a story? Review 1. Split and conquer! 2. Cut in slices 3. Split before an iteration to get the size right 4. Split at the end of an iteration to declare the iteration complete
- 56. Story Smells
- 57. Story Smells Stories are too small Symptom: A frequent need to revise estimates Small stories may be implementation order dependent
- 58. Story Smells Goldplating Symptom: Developers adding features/enhancements that are not planned for the iteration • Seeking the Wow factor • Pet features
- 59. Story Smells Too much detail Symptom: Writing stories takes more time than talking stories • Too much detail to early • If it cannot fit on an index card it is too long • Hard to estimate
- 60. Story Smells Thinking too far ahead Symptoms: • Stories are hard to fit on a card • Need for using a software system rather than cards • Common among teams accustomed to large up front "requirements" engineering efforts • Suggesting the use of template user story docs • Reminder what stories are, and recognition that it is impossible to have all requirements and details
- 61. Story Smells Customer has trouble prioritizing • Prioritizing is difficult • Consider reviewing the size • Lack of biz value • Too technical, the owner does not get it • Let the customer write the stories, be part of it
- 62. Story Smells Review 1. Sharpen your senses 2. If it is too hard too often it ain’t right 3. Address issues early 4. Good judgment comes from experience, and experience comes from bad judgment
- 63. Reading
Notas do Editor
- Stories are a reminder of a conversation Stories (and requirements) are rarely complete description (only fantastic stories and perfect requirements do that) Safe time to document quickly changing facts Quick feedback Avoid conflicts Example “As an Administrator I want the system to constantly make sure it is healthy so that I don't have to worry about it”
- Stories are a reminder of a conversation Stories (and requirements) are rarely complete description (only fantastic stories and perfect requirements do that) Safe time to document quickly changing facts Quick feedback Avoid conflicts Example “As an Administrator I want the system to constantly make sure it is healthy so that I don't have to worry about it”
- Stories are a reminder of a conversation Stories (and requirements) are rarely complete description (only fantastic stories and perfect requirements do that) Safe time to document quickly changing facts Quick feedback Avoid conflicts Example “As an Administrator I want the system to constantly make sure it is healthy so that I don't have to worry about it”
- Understandable by both users and developers Studies show that stories are easier to remember Short Concentrate on a specific business value proposition
- Issues with this story: Fake user No clear business value Use of words that are of no value to the REAL user (think the participant persona)
- Issues with this story: Fake user No clear business value Use of words that are of no value to the REAL user (think the participant persona)
- Issues with this story: Fake user No clear business value Use of words that are of no value to the REAL user (think the participant persona)
- User stories are the right size for planning – not too big, not too small, but just right To make that happen we constantly change stories: Stories are not static -Stories can be split Later we’ll talk about how to make that happen In agile resources do not change: Iteration duration is constant Number of team members does not change during the iteration Stories CHANGE
- No need to write all stories to start coding (unlike traditional requirements) Takes little time to write them, change them and prioritize them Start with an epic and split in each iteration (getting there….)
- Writing quickly dozen stories gives a time saving overview of what the project would or may include. Only the most valuable stories get dealt with in detail and get implemented. Keep in mind when communicating with the design team
- Be aware when discussing the stories at different stages of the development process Release planning – no details (only enough for a rough estimate) Iteration planning – increasing detail (enough to create tasks, acceptance criteria and estimates) Iteration – maximum detail (deep dive) Feel free to raise the flag! Use timer to timebox discussions.
- Bringing out tacit knowledge – With tacit knowledge, people are not often aware of the knowledge they possess or how it can be valuable to others. Effective transfer of tacit knowledge generally requires extensive personal contact and trust. Tacit knowledge is not easily shared. Tacit knowledge consists often of habits and culture that we do not recognize in ourselves. Tacit knowledge refers to a knowledge which is only known by an individual and that is difficult to communicate to the rest of an organization. Knowledge that is easy to communicate is called explicit knowledge. Tacit knowledge has been described as “know-how” -- as opposed to “know-what” (facts), “know-why” (science), or “know-who” (networking). It involves learning and skill but not in a way that can be written down.
- Be aware when discussing the stories at different stages of the development process Release planning – no details (only enough for a rough estimate) Iteration planning – increasing detail (enough to create tasks, acceptance criteria and estimates) Iteration – maximum detail (deep dive) Feel free to raise the flag! Use timer to timebox discussions.
- Stick to a common format, helps capture value and makes reading even easier Ask audience how would they split this is taks Look at this story from different point of views Police department Bucket manufacturer Candy manufacturer Costume manufacturer Parent
- Stick to a common format, helps capture value and makes reading even easier Ask audience how would they split this is tasks Look at this story from different point of views Police department Bucket manufacturer Candy manufacturer Costume manufacturer Parent
- Stick to a common format, helps capture value and makes reading even easier Ask audience how would they split this is taks Look at this story from different point of views Police department Bucket manufacturer Candy manufacturer Costume manufacturer Parent
- If it is too long to fit a piece of paper it is probably too long. (Ask for suggestions on how do we address this in Rally?)
- Not final and not a contract Most of it is not documented There is no “most recent version” Avoid numbering – issue with our stories http://hotspot/Development/Product%20Teams/Empower/Documents/Version%201.0/Product%20Requirements/Product%20Requirements.EmpowerDocumentManagement%20Release%201.0.xlsx
- No value, no priority, cannot change once it is written, no persona or role! Example: http://www.access-board.gov/sec508/guide/1194.22.htm
- Twist to “as a retired man in his 60s…..”
- All stake holders should understand it: User Product owner Developer Tester
- All stake holders should understand it: User Product owner Developer Tester
- All stake holders should understand it: User Product owner Developer Tester
- Show Tommy’s Builder use case and scenarios document The content of the story card + acceptance tests = use case They differ by the level of completeness.
- Show Tommy’s Builder use case and scenarios document
- also known as interaction design scenarios It is even bigger that a use case very complete description of the interactions. Includes several use cases. Example the builder design documents http://hotspot/Development/Product%20Teams/Empower/Documents/Version%201.0/Product%20Design/DM_userscenario2.pdfhttp://hotspot/Development/Product%20Teams/Empower/Documents/Version%201.0/Product%20Design/DM_userscenario.pdf
- Includes : a setting Multiple actors Goals and objectives Actions and events – plot Contains many possible stories
- All stake holders should understand it: User Product owner Developer Tester
- All stake holders should understand it: User Product owner Developer Tester
- Customer Team Ideally there would be one person to write stories, prioritize work and answer questions, but... Can be made of testers, technical writers, product manager, real users, interaction designers This team prioritizes work for developers and answers questions
- Point out that this is “As is…”
- Add a chart with some stories based on the previous
- Add a chart with some stories based on the previous
- Show real docs
- Show real docs
- Avoid splitting on actions. The story should be feature complete no dependency on other stories
- Avoid splitting on actions. The story should be feature complete no dependency on other stories
- Complex story Split in investigation(spike) and implementation story Spikes need a timebox New features can be split in Design/Research and implementation story Research may be difficult to estimate Consider putting the spike or the research in a different iteration. Make estimate only for the spike/research stories and leave the implementation story estimate for later
- Avoid splitting on actions. The story should be feature complete no dependency on other stories
- Split incomplete stories at the end of the iteration If story is unfinished at the end of approaching the end of the iteration, either split or move to the next iteration
- Who? Builder/Admin/Participant? What parts of the standard? (a) Text Tags (b) Multimedia Presentations (c) Color (d) Readability (e) Server-Side Image Maps (f) Client-Side Image Maps (g)&(h) Data Table (i) Frames (j) Flicker Rate (k) Text-Only Alternative (l) Scripts (m) Applets and Plug-Ins (n) Electronic Forms (o) Navigation Links (p) Time Delays
- Who? Builder/Admin/Participant? What parts of the standard? (a) Text Tags (b) Multimedia Presentations (c) Color (d) Readability (e) Server-Side Image Maps (f) Client-Side Image Maps (g)&(h) Data Table (i) Frames (j) Flicker Rate (k) Text-Only Alternative (l) Scripts (m) Applets and Plug-Ins (n) Electronic Forms (o) Navigation Links (p) Time Delays
- Who? Builder/Admin/Participant? What parts of the standard? (a) Text Tags (b) Multimedia Presentations (c) Color (d) Readability (e) Server-Side Image Maps (f) Client-Side Image Maps (g)&(h) Data Table (i) Frames (j) Flicker Rate (k) Text-Only Alternative (l) Scripts (m) Applets and Plug-Ins (n) Electronic Forms (o) Navigation Links (p) Time Delays http://www.access-board.gov/sec508/guide/1194.22.htm
- Who? Builder/Admin/Participant? What parts of the standard? (a) Text Tags (b) Multimedia Presentations (c) Color (d) Readability (e) Server-Side Image Maps (f) Client-Side Image Maps (g)&(h) Data Table (i) Frames (j) Flicker Rate (k) Text-Only Alternative (l) Scripts (m) Applets and Plug-Ins (n) Electronic Forms (o) Navigation Links (p) Time Delays http://www.access-board.gov/sec508/guide/1194.22.htm
- Split incomplete stories at the end of the iteration If story is unfinished at the end of approaching the end of the iteration, either split or move to the next iteration