Epic Sharding
Anyone familiar with agile has heard of the concept of user stories. According to every agile diagram, all you need to build software is user stories!
Except software development doesn’t quite work that way.
tl;dr: If your story gherkin contains multiple “and then”, you’re doing it wrong.
User stories, as employed in building the Great Pyramid
(from a Mike Cohn presentation on user stories)
The problem:
You have a beautiful workflow you want to implement. You write your user story. Nay, you birth your Novella of a story. You print it out and send it your mother who gushes with pride and hangs it on the fridge.
And then you talk it through with your developers
“8 points?!”, you exclaim.
“Well, there’s a lot to build here, and we aren’t really sure what this doohickey in the corner does. We’ve never done anything like that before. Can you break these stories up?”
You: “Why would I break this up? I need all of it!”
And therein lies the rub: You can’t release a half-baked feature but developers are giving high estimates so now you’ll never see your feature. What you have is actually an Epic: a large user story. So how do you build this thing? You get short.
Short Stories > Long Stories
Small stories are better than long stories (except at bedtime) because:
– You are iteratively delivering value to the user
– Developers can accurately estimate smaller pieces
– Your velocity maintains a steady pace
– Your volatility remains smooth
– You’re seeing functionality delivered faster than a large story.
– Developers are humans too, and nobody wants to be working on the same story for a week.
Here’s a few ways to break your epic into dev-palatable pieces:
Break up functionality:
Every story should deliver value to the user. But it doesn’t need to be a large amount of value.
For example:
MEH: All functionality in one story
As a user who is updating a task, when I click ‘Complete’
Then the task should save
And the left-pane should remove this task from the Incompleted Tasks list
And the badge count in left-pane should decrease for Incompleted Tasks
And the left-pane should show this record in the Completed Tasks list
And the badge count in the left-pane should increase for Completed Tasks
How many ‘ands’ can you spot? You’re looking at a minimum three point stretch.
These multiple conditions make estimating difficult, and delivery very far away
BETTER:
Break this up into three separate stories:
1) User can save a record and mark it as complete
2) User sees the record removed from the Incompleted Records list in the left pane (and badge count decreases)
3) User sees the record added to the Completed Records list in the left pane (and badge count increases)
With this approach you can release the main feature (updating a record and marking as complete), and then build the two nicer-to-have features.
NOTE: You may be tempted to split your stories into front and back-end pieces to appease dev teams. Don’t do this because it won’t deliver any user value, and you won’t be able to accept the story. What would the user say if they could fill out the form, but clicking ‘Complete’ didn’t save their Task?
Happy / Sad Paths
Aptly titled, a happy path is the desired steps you want the user to complete. The sad path(s) are all the exceptions or edges cases. Instead of writing one story that lists all possible use cases (weren’t you clever though!), break them into specific instances.
For example, take a landing page where a user can sign in:
MEH: One story for every scenario
Story: “As a user I should be able to sign in to our perfect product”
Scenario: User signs in with correct username and password
Given that I am a user with a correct username and password
And I click ‘Sign In’
Then I should be shown my dashboard
Scenario: User doesn’t sign in with correct username and password
Given…… (you get the idea)
BETTER: Create individual stories for each scenario
– User can sign in with correct username and password
– User sees error message when signing in w/incorrect username…
– User sees error message when they haven’t confirmed their account
– User sees error message when account doesn’t exist.
FEATURE FLAGGING:
Let’s say you’re building DMV 2.0 and you require your users to fill out a four page form (previously seven!). In your infinite wisdom you’ve broken this form into four stories that make development easier – but your soon-to-be drivers still need to fill out the entire form.
Feature flagging is adding logic in the code that ‘hides’ this new functionality until you’re ready. Each accepted story goes out to production, but behind a curtain. The advantage is that you’re not disrupting your regular release cycle by waiting for all features to be done. When you’re ready to show this functionality, flip a switch in the admin console, or remove the logic before your next release. The old way of hiding code was dangerous: merging that code branch for staging, and then hopefully remembering to remove on production release.
This can be extended even further to beta test new functionality to a subset of users. But be careful with feature flagging, it does add development time for this logic. It may also interfere with current functionality when features overlap.
Want to see other approaches to further julienne your stories? Check out this great flowchart developed by AgileForAll.com
A great flowchart for splitting stories (agileforall.com)
Do you already know all this stuff? Know someone that doesn’t? Help them grow by using the share links below.
About the Author
