Slicing user stories
•Download as PPTX, PDF•
9 likes•1,626 views
How to slice user stories, using concepts like low/high fidelity solutions, iterative vs incremental delivery, and hunting for small bits of value rather than breaking down work in technical chunks.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (14)
Similar to Slicing user stories
Similar to Slicing user stories (20)
Recently uploaded
Recently uploaded (20)
Slicing user stories
- 1. David Michel 25 October 2016 Slicing User Stories @DavMichel76
- 2. Requirements in Scrum? Product Backlog Item User story
- 5. How to break down large user stories
- 6. Let’s NOT break things down in “waterfall” phases… Implement Test Deploy + +
- 8. Let’s explore some of the tools & techniques
- 9. Slicing by workflow As customer I want to review and confirm my order, so I can correct mistakes before I pay As customer I want to pay for my order with paypal, so I don’t have to look for my credit card As customer I want to receive a confirmation e-mail with my order, so I have proof of my purchase
- 10. Slicing by operation As shop owner I want to add new products, so customers can purchase them As shop owner I want to update existing products, so I can adjust for changes in pricing or product information As shop owner I want to delete products, so I can remove products that I no longer stock
- 11. As site owner I want to be able to request a new password when my login fails, so that I can try to log in again Slicing by unhappy As site owner I want to block users with 3 failed log in attempts in a row, so I can protect the site against hackers As user I want to log in with my account, so that I can access secure pages
- 12. Slicing by “0>1>many” As a chef, I want to view a customer’s order with no items so I can proceed with the cooking As a chef, I want to view a customer’s order with one item so I can proceed with the cooking As a chef, I want to view a customer’s order with multiple items so I can proceed with the cooking
- 13. There are many, many more techniques… • Splitting User Stories Presentation http://www.slideshare.net/arsenalist/splitting-userstories • Splitting User Stories Cheat sheet https://twitter.com/chrisverwijs/status/335109871802384385 • Breaking Down Larger Stories http://agileinaflash.blogspot.co.uk/2009/02/breaking-down-larger-stories.html • User Story Hamburger technique https://gojko.net/2012/01/23/splitting-user-stories-the-hamburger-method/ • Features to User Stories http://idiacomputing.com/pub/UserStories.pdf • Patterns for spitting user stories http://agileforall.com/patterns-for-splitting-user-stories/ • Twenty Ways to Split Stories http://xp123.com/articles/twenty-ways-to-split-stories/
- 14. This was easy, right?
- 15. Where the magic happens Your comfort zone
- 17. Not horizontally
- 21. Simple to complex Slicing by fidelity http://availagility.co.uk/2009/12/22/fidelity-the-lost-dimension-of-the-iron-triangle/
- 23. As a gardener, I want to use a So that I can plant this or or or
- 24. As a I want to So that . Expected outcome Action Persona How do we know this is the best action to take? Maybe there’s a better way. Too many assumptions http://alanklement.blogspot.co.uk/2013/09/replacing-user-story-with-job-story.html
- 25. • Impossible to define any kind of acceptance criteria • Rarely expressed in a way that would make them appear valuable from the perspective of the stakeholders Slicing by “learn vs. earn” Spikes https://leanpub.com/50quickideas
- 26. Instead of slicing technical deliverables and then looking for useful chunks of value… Slicing by value …Try to start from the opposite direction: slice value and look for useful technical chunks https://leanpub.com/50quickideas
- 27. Slicing by “0>1>many” As a chef, I want to view a customer’s order with no items so I can proceed with the cooking As a chef, I want to view a customer’s order with one item so I can proceed with the cooking As a chef, I want to view a customer’s order with multiple items so I can proceed with the cooking This break down seems particularly artificial. The technical breakdown makes sense to developers but doesn’t bring value to the user!
- 28. Instead of slicing technical deliverables and then looking for useful chunks of value… Slicing by value …Try to start from the opposite direction: slice value and look for useful technical chunks https://leanpub.com/50quickideas
- 29. Backlog Refinement Process Danger of breaking down things we already know a lot about… leaving the large, not yet understood items and at the bottom of the backlog
- 30. Danger of breaking down things we already know a lot about… leaving the large, not yet understood items and at the bottom of the backlog Spike to learn Earn by 1st delivering low-fidelity solution Then iterate towards more refined
- 31. How do you slice your stories?
Editor's Notes
- Take Scrum, you have a product backlog that contains so-called “product backlog items”… and if you look at the official Scrum guide, that term is the only thing you’ll learn about it. The framework doesn’t actually tell you anything how what that should look like, or how to come up with them, their granularity, etc. It’s up to you! What most Agile practitioners do is borrow the concept of user stories from XP (Extreme Programming), first introduced by Kent Beck, and later popularised by Mike Cohn
- So the question is: what’s the right granularity/size ?
- Often, there is a refinement process (used to be called grooming) that teams go through so you break down large stories (epics) into smaller ones… which helps with prioritising the sprints.
- And of course comes the question of how does one break large stories…
- Let’s not break things down in “waterfall” phases… This one is obvious, so I’m not going to dwell on it.
- Split by workflow By breaking up a large user story like this, we have improved our understanding of the functionality and our ability to estimate. It will also be easier for a product owner to make decisions about priority. Some workflow steps may not be important right now and can be moved to future sprints. Perhaps the order confirmation mail can be done by hand for the time being, customers can only pay with credit card for now, or customers are temporarily required to enter their personal information for every order. This will certainly limit the functionality of the online shop, but it does allow a Scrum Team to review the completed functionality at the end of the sprint, test it (perhaps by going live) and use the feedback to make necessary changes
- Split by operation e.g. CRUD When presented with this strategy, many teams wonder if the smaller items actually deliver business value. After all, what's the point of only creating entities, when you cannot update or delete them afterwards? But perhaps the product owner has such a limited number of products, that editing or deleting can be done through a database manager directly. Sometimes, an operation can be easily implemented in a simplified form. Deleting a product can be done in two ways; you can completely drop the record and all associated records, or you can 'soft delete' a product. In that case, the product is still in the database, but it is marked as 'deleted'. Sometimes one of these approaches is easier to implement, and can be 'good enough' for now.
- Functionality often involves a happy flow and one or more unhappy flows. The happy flow describes how functionality behaves when everything goes well. If there a deviations, exceptions or other problems, unhappy flows are invoked. Take this user story for logging in to a secure website: Unhappy flows describe exceptions. By identifying the various flows, we more clearly understand the required functionality. A product owner can also more easily decide what is important right now. Perhaps blocking users after three failures is not important because there are only a handful of users in the first version. Or perhaps a reset of passwords can be done by sending an e-mail to a support employee for the time being. Again, by splitting up functionality we can more accurately ask questions about the business value, and make decisions accordingly.
- Split by 0, 1, many Useful for splitting stories that deal with multiple instances of something into stories that deal with no instance, then one instance, then many instances. Handle the empty scenario first.
- Thin vertical slicing is a term that is often coined in the Agile community and represents the preferred way to slice work. It means considering small bits of functionality and consider, as part of the task at hand, all the architectural layers of the application. That’s the only way to deliver something that is actually useful to the user. E.g. if you haven’t done the database bit, it’s not complete.
- So you don’t want to slice horizontally, that is to say, per architectural layers.
- This is what this would look like… You don’t want to do that because, when the user story is completed, well… it’s not useful to the user. Think about the term “user story”. Can the user accomplish the story he has in mind when one of this card is complete…. No! How can a product owner prioritize a backlog if it consists of horizontal slices? Because none of the items deliver business value in themselves, a product owner will be unable to prioritize the work. There is also a good chance that the slices will be fairly technical, which makes it even harder and creates distance and misunderstanding between the product owner and the team;
- So, in fact, contrary to my title… we don’t really want to split user stories, we want to be making them thinner and thinner.
- One my favourite ways to doing this is this: Fidelity slicing… Means going from simple to complex. Low fidelity does not mean low quality though… you can have low-fidelity solution that is high quality…. We don’t want to go low quality, ever.
- When you slice by fidelity and thus iterate, suddenly, you have options, potentially lots of them… which can be more or less complex as well as very simple.
- Explore options to change the “I want to” part of the user story, keeping the goal in mind
- http://www.lagerweij.com/2013/04/12/spikes-theyre-sharp/
- Split by value… a nice segway to your talk?
- Remember this slide? The value part here doesn’t quite make sense, does it? Why would a chef want to start cooking an empty order? This is what can happen when we slice by technical chunks… it can be quite hard to find value out of them…
- Split by value… a nice segway to your talk?
- Caution about refinement process that focuses on breaking down things we know a lot about and leaving the stuff we don’t much about at the bottom of the backlog because they are large. This leaves the unknown to be dealt later… this is a rather risky strategy. They should be dealt with as soon as possible (spikes!.... I don’t seen many teams doing enough spikes… if you don’t spikes at all, that means you know everything, and if you know everything, than why are you doing Agile… I don’t want to use agile just to cope with the possibility of a change… I want to use it as a learning opportunity, to learn about what the end-users really need)