The Untold User Story
•Download as PPTX, PDF•
1 like•97 views
What makes user stories effective in agile projects? This session goes through the reason we use user stories, tips and tricks and about slicing stories and story mapping.
More Related Content
Similar to The Untold User Story
Similar to The Untold User Story (16)
More from Gil Zilberfeld
More from Gil Zilberfeld (18)
Recently uploaded
Recently uploaded (20)
The Untold User Story
- 2. @gil_zilberfeld Hello! I AM GIL ZILBERFELD www.gilzilberfeld.com www.everydayunittesting.com @gil_zilberfeld
- 3. @gil_zilberfeld What are user stories anyway?
- 4. @gil_zilberfeld A user story As a User I want to press the “Send” button In order to make the payment
- 5. @gil_zilberfeld “The original intent is that what you build is *so* amazing that users tell stories about how amazing it is.” Kent Beck
- 6. @gil_zilberfeld What’s the story? ◉ The who, why and what of stories ◉ Effective stories ◉ Slicing stories ◉ Story mapping
- 8. @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.”
- 9. @gil_zilberfeld Stakeholders ◉ Users ◉ Customers ◉ Builders ◉ Regulators ◉ Bystanders
- 10. @gil_zilberfeld Categorizing stakeholders ◉ Roles ◉ Jobs to be done (JTBD) ◉ What’s important for them? ◉ How does the product impact their lives?
- 11. @gil_zilberfeld
- 12. @gil_zilberfeld Goal “A goal is a desired result that a person or a system envisions, plans and commits to achieve.”
- 13. @gil_zilberfeld Goals ◉ What do the stakeholders want to achieve? ◉ Goals can be defined as outcomes ◉ More, Better, faster, cheaper…
- 14. @gil_zilberfeld
- 15. @gil_zilberfeld Capability “An ability to perform or achieve certain actions or outcomes through a set of controllable and measurable faculties, features, functions, processes, or services.”
- 16. @gil_zilberfeld Capabilities ◉ How can our product help the stakeholder achieve their goal? ◉ Product gives capabilities ◉ Features in context
- 19. @gil_zilberfeld How does the “As a user…” format help us? And when it doesn’t?
- 20. @gil_zilberfeld Ron Jeffries said As an 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
- 21. @gil_zilberfeld “A user story is a ticket for a conversation” Ron Jeffries
- 22. @gil_zilberfeld
- 23. @gil_zilberfeld What makes stories effective?
- 24. @gil_zilberfeld Better user stories ◉ Unveil the motive – what is the goal and for which stakeholder? ◉ Consider dropping the template ◉ Tell the story in a sentence or two ◉ Anchor it – how does it fit with what we have or know?
- 25. @gil_zilberfeld Better user stories ◉ Describe the demo ◉ Give more context ◉ The general rules ◉ And the exception to the rules
- 26. @gil_zilberfeld Questions about the stories ◉ Are the stories ready for work? ◉ How complex are they? ◉ Do they fit in a sprint? ◉ Do we need to do a POC? ◉ Does the story have sub-stories? ◉ What alternatives do we have for implementation? ◉ What will we learn?
- 27. @gil_zilberfeld
- 28. @gil_zilberfeld
- 29. @gil_zilberfeld SFDIPOT – A slicing heuristic
- 30. @gil_zilberfeld
- 31. @gil_zilberfeld Story Mapping “A technique that takes a user-centric perspective for generating a set of user stories.”
- 33. @gil_zilberfeld User Story Mapping - Examples https://realtimeboard.com/examples/user-story-map/
- 34. @gil_zilberfeld User Story Mapping - Examples http://agileconsulting.blogspot.co.il/2012/05/integrating-story-mapping-with-kanban.html
- 35. @gil_zilberfeld Summary ◉ Identify the stakeholders, their goals, and the capabilities ◉ Effective stories have enough information to start discussing working ◉ Story maps give us direction by showing the whole picture
- 36. @gil_zilberfeld Thanks! ANY QUESTIONS? You can find me at: @gil_zilberfeld http://www.GilZilberfeld.com http://www.EverydayUnitTesting.com
Editor's Notes
- Good narrative, but cannot be tested
- Good narrative, but cannot be tested
- 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.
- 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.