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.
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/
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
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
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)