Downloaded 56 times
Uploaded byGil Zilberfeld
A Horror Story
This document discusses slicing user stories to make them smaller and more manageable for testing. It recommends slicing stories based on stakeholders, capabilities, acceptance criteria, and edge cases. Stories should be written to describe a desired outcome or capability without rigid templates. The goal of slicing is to have independent, negotiable, valuable, and testable stories that provide short feedback cycles for continuous learning and improvement.
More Related Content
More from Gil Zilberfeld
A Horror Story
- 1.
- 2. @gil_zilberfeld Hello! I AM GILZILBERFELD www.gilzilberfeld.com www.everydayunittesting.com @gil_zilberfeld
- 3. @gil_zilberfeld What’s the story? ◉Some theory ◉ Stakeholders ◉ Effective stories ◉ Slicing heuristics ◉ Examples
- 4. @gil_zilberfeld Some theory… It’s slicingall the way down
- 5.
- 6.
- 7. @gil_zilberfeld Testing ◉ Simpler todo the smaller it gets ◉ Easy to focus ◉ Easy to explore
- 8. @gil_zilberfeld Shorter feedback cycles ◉Ideas ◉ Products ◉ Releases ◉ Features ◉ Stories
- 9. @gil_zilberfeld Ideas Products Releases Features Stories MVPs Small frequent releases Minimaluser journeys Minimal functionality Working testable functionality Slicing down
- 10.
- 11.
- 12. @gil_zilberfeld Testicorn – Akiller app The ghost of the testing unicorn that terrorizes the city of Potsdam
- 13.
- 14. @gil_zilberfeld Stakeholder “An individual, group,or organization, who may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project.”
- 15. @gil_zilberfeld Stakeholders ◉ Users ◉ Customers ◉Builders ◉ Regulators ◉ Bystanders
- 16. @gil_zilberfeld Categorizing stakeholders ◉ Roles ◉Jobs to be done (JTBD) ◉ What’s important for them? ◉ How does the product impact their lives?
- 17. @gil_zilberfeld Who are thestakeholders of Airbnb?
- 18. @gil_zilberfeld Exercise: Testicorn stakeholders ◉List them ◉ Categorize them ◉ Rate them
- 19.
- 20.
- 21.
- 22. @gil_zilberfeld Goal “A goal isa desired result that a person or a system envisions, plans and commits to achieve.”
- 23.
- 24. @gil_zilberfeld Capability “An ability toperform or achieve certain actions or outcomes through a set of controllable and measurable faculties, features, functions, processes, or services.”
- 25. @gil_zilberfeld Exercise: Stakeholders goalsand capabilities ◉ What is important to our stakeholders? ◉ What do they want to achieve? ◉ What options do we have to meet the goals? ◉ Prioritize them
- 26.
- 27. @gil_zilberfeld Why do weneed to slice stories?
- 28. @gil_zilberfeld Questions about stories ◉Are the stories ready for work? ◉ Do they fit in a sprint? ◉ How complex are they? ◉ What will we learn? ◉ What options do we have for implementation? ◉ Do we need to do a POC? ◉ Does the story have sub-stories?
- 29.
- 30. @gil_zilberfeld Mind Map “A diagramused to visually organize information.”
- 31. @gil_zilberfeld Mind maps ◉ Acollaborative tool ◉ Usually a tree, but doesn’t have to be ◉ Helps in slicing stories and cases ◉ Helps in prioritizing what we’re going to build and test
- 32. @gil_zilberfeld Exercise: Slicing stories ◉Review the story maps ◉ Create a mind map for stories ◉ What are the regular and special cases? ◉ What is the happy path? How do we know we’re there?
- 33. @gil_zilberfeld SFDIPOT – Aslicing heuristic
- 34. @gil_zilberfeld Exercise: Slicing stories ◉Enhance the mind maps ◉ Think of the others aspects as well ◉ Types of users ◉ Types of complexity ◉ Types of “what ifs”
- 35.
- 36. @gil_zilberfeld Why do wecall them stories anyway?
- 37.
- 38. @gil_zilberfeld The template As a… I want a … In order to …
- 39. @gil_zilberfeld The template As akiller unicorn I want to get near a victim In order to kill it
- 40. @gil_zilberfeld What is theacceptance criteria?
- 41. @gil_zilberfeld Give me anexample!
- 42. @gil_zilberfeld The template As akiller unicorn I need to be at least 12 steps from a victim In order to kill it
- 43.
- 44.
- 45. @gil_zilberfeld Ron Jeffries said Asan author of the Agile Manifesto I want that stupid story format to go away So that people can get to the essence of user stories
- 46. @gil_zilberfeld “A story isa ticket for a conversation”
- 47.
- 48. @gil_zilberfeld Better user stories ◉Drop the template ◉ Tell the story in a sentence ◉ Anchor it ◉ Unveil the motive
- 49. @gil_zilberfeld Better user stories ◉Imagine the demo ◉ Give context ◉ The general rules ◉ Exception to the rules
- 50. @gil_zilberfeld Exercise: Writing stories ◉Write and present stories ◉ What are the essential parts? ◉ What must work? ◉ What are the fail safes?
- 51.
- 52.
- 53. @gil_zilberfeld Thanks! ANY QUESTIONS? You canfind me at: @gil_zilberfeld http://www.GilZilberfeld.com http://www.EverydayUnitTesting.com
Editor's Notes
- #19 15 mins?
- #39 Good narrative, but cannot be tested
- #40 Good narrative, but cannot be tested
- #41 A scenario has 3 parts, like AAA. In fact 4, also clean up. We need to specify an acceptance criteria, otherwise we can’t know if our “test” passes really or by accident. In unit tests we have Asserts. This is different than DoD For each test/story/scenario we need the same.
- #43 Good narrative, but cannot be tested
- #46 Good narrative, but cannot be tested
- #49 Drop the template. Like everything, once we have a hammer we start looking for nails. Sometimes the template doesn't fit. That's ok. In that case... Tell the story in a sentence. Maybe two. When people are presented with a new idea, don't make them read heaps of documents. Sum it up, so they can grasp it quickly. Details can come later. And make sure it's a story, with a beginning, middle and an end. People remember and consume stories better. You can even sing it if you want, that would make it more memorable. Next you want to... Anchor it. You know the "It's like Uber, but for...?" pitch form every start up is using? Everybody knows Uber, so they have something to reference the new information. In story-land it's how the story fits into the application. "It's like the log-in story from last week, but with extra validation". Or, "Once we've done with the simple path, we can add more informed algorithms". You're showing where we were, where we're going, and where this story fits. Then it gets interesting. Unveil the motive. Why are we developing this anyway? Who is going to benefit and how? The user may be able to go through registration quicker, and that means more happy users. Or we, the company, gets more money from the dog accessories suppliers, if we're able to connect our users based on their level of pet appreciation. There's a reason we're developing the feature, and it really helps to know the final goal. In some cases, we can debunk it, and choose something better to do with our time. Once people understand the motive... Make a show. How does it look like? You have prepared some mock-up screens, or sketches, or drawing of a flow, or anything that has more meat, right? Ah, you need to prepare for this, young Padawan. It will help, not just with explaining it, but it's a also the setting for... Give it context.Now that things begin to materialize, it's time for an example. You can present the flow on those mocked screens. Or how a different application might be using our new API. How future features will be using our back-end calculation results. Context is awesome! We can use it to direct the team towards... Generalize. Do we start with the example and just implement it? Should we write a more extensive data validation layer, and then test it? Somewhere in between? An example is not enough for development, because we need to know where to stop. And we need to know how to test. This really helps with defining the acceptance criteria. The final step is... Draw a line in the sand. Some things do not fall into our general rule. VIPs do not need to enter their credentials again. Anonymous users can use the applications, but will go through a separate flow we'll define later. Anything that does not fall within our boundaries, should be presented. Otherwise, we would implement it, and test it, and we will be surprised. And we don't like surprises.
- #50 Drop the template. Like everything, once we have a hammer we start looking for nails. Sometimes the template doesn't fit. That's ok. In that case... Tell the story in a sentence. Maybe two. When people are presented with a new idea, don't make them read heaps of documents. Sum it up, so they can grasp it quickly. Details can come later. And make sure it's a story, with a beginning, middle and an end. People remember and consume stories better. You can even sing it if you want, that would make it more memorable. Next you want to... Anchor it. You know the "It's like Uber, but for...?" pitch form every start up is using? Everybody knows Uber, so they have something to reference the new information. In story-land it's how the story fits into the application. "It's like the log-in story from last week, but with extra validation". Or, "Once we've done with the simple path, we can add more informed algorithms". You're showing where we were, where we're going, and where this story fits. Then it gets interesting. Unveil the motive. Why are we developing this anyway? Who is going to benefit and how? The user may be able to go through registration quicker, and that means more happy users. Or we, the company, gets more money from the dog accessories suppliers, if we're able to connect our users based on their level of pet appreciation. There's a reason we're developing the feature, and it really helps to know the final goal. In some cases, we can debunk it, and choose something better to do with our time. Once people understand the motive... Make a show. How does it look like? You have prepared some mock-up screens, or sketches, or drawing of a flow, or anything that has more meat, right? Ah, you need to prepare for this, young Padawan. It will help, not just with explaining it, but it's a also the setting for... Give it context.Now that things begin to materialize, it's time for an example. You can present the flow on those mocked screens. Or how a different application might be using our new API. How future features will be using our back-end calculation results. Context is awesome! We can use it to direct the team towards... Generalize. Do we start with the example and just implement it? Should we write a more extensive data validation layer, and then test it? Somewhere in between? An example is not enough for development, because we need to know where to stop. And we need to know how to test. This really helps with defining the acceptance criteria. The final step is... Draw a line in the sand. Some things do not fall into our general rule. VIPs do not need to enter their credentials again. Anonymous users can use the applications, but will go through a separate flow we'll define later. Anything that does not fall within our boundaries, should be presented. Otherwise, we would implement it, and test it, and we will be surprised. And we don't like surprises.