This is something that helps every Agile team I work with but especially the distributed ones: make stories as small as possible — especially where “as small as possible” means “the smallest amount of work I have to explain to someone else”.
If your UX person is in Location A, your Java Developer is in Location B, your Product Owner is in Location C, and your Quality Engineer is in Location D, it is inevitable that assumptions over what’s in scope and out of scope for a story (not to mention how it looks and behave) are going to be made.
Let’s say we’re redesigning a login page. On any of my co-located teams, the story would probably be:
- As a user I want to log into the site
The acceptance criteria would include:
- Create the page with its title attribute and heading set appropriately
- Put the fields on the page
- Put the content on the page
- Put the client-side validation on the page
- Put the server-side validation on the page
- Handle n use cases of validation (where each would be its own acceptance criteria)
- Ensure the whole thing matches this wireframe when you’re done
- Ensure the whole thing passes accessibility criteria
When the story is written this way, the story represents a deliverable piece of business value. Before, the user could not log in, now the user can.
For each of the acceptance criteria, we would discuss the details of the acceptance criteria, how to put it together, and how and when to test it — and the story would probably take about a week to be completed. This “works” for that team because everyone is co-located so theoretically we can yell over the cube walls at each other for clarification on details.
In reality, the Developer makes a lot of assumptions while the PO and I are at other meetings, the QE makes a lot more assumptions, I get the story after QE and start asking questions about the assumptions, and we open probably 2 to 3 defect tickets late in the sprint. It gets worse when we’re not co-located because it’s easier to just not ask questions when asking questions involves typing and not, say, hollering over the wall.
On the distributed teams, a single story would be:
- Create the page with its title attribute and heading set appropriately
In this case the acceptance criteria would include
- Here’s the URL it should be set to
- Here’s the H1 content it should be set to
- Here’s the title attribute content
- Here’s the accessibility criteria
- Here’s the wireframe for visual reference, remember we’re only looking at the H1 from the wireframe.
Now, the team still put the acceptance criteria together, and they still sized it together, but this time we’ve written all the details at the microscopic level, so there’s a lot less relying on memory and a lot less sending each other messages on Slack that say “hey do you remember what we said about…?” Yes, we probably still make assumptions, but there’s a lot less to make assumptions about. And there’s a much lower chance that we’re opening defects against this story.
While the single story for the co-located team would take a week, this team has 5-10 stories for the same work, and it still takes a week. Testing feels like it takes a little longer, but that’s because the testable criteria is better outlined. (And it doesn’t always feel longer because when stories are small sometimes the QE can knock one out in the time between meetings, whereas big stories have to be saved for larger chunks of time.)
When the stories are written this granularly, a single story doesn’t represent business value, the business value is captured at the epic/feature level. But that’s OK because:
- both teams get the same amount of work done in the same amount of time
- both teams still release the same amount of work to production before the user sees it
- the “smaller stories” approach delivers higher quality software with less rework
Most importantly, the “smaller stories” approach provides written documentation that anyone on the team can quickly read and understand to know what the heck they’re building that day. Nobody has to be in the same room — they don’t even have to be working the day the story was written — to recognize what a story is asking for when it arrives in their queue.
It doesn’t mean we’re not collaborating. Instead of collaborating mid-sprint, we’re collaborating during planning.
It doesn’t mean we’re not making changes when they’re necessary. Because the work is smaller, we can be more agile in our approach to problems when they arise, and other parts of the story can still be marked as complete.
And yes, it does mean we’re writing more “documentation”, but we’re still not writing 70-page requirements docs. Remember, when the Agile Manifesto referenced “working software over comprehensive documentation” they were reacting to the Waterfall requirements-specification-first approach to developing software. They were not saying “OMG never write anything down”.
It’s always important to ensure that we’re writing stories that anyone can pick up and understand. It’s even more important when we’re in the middle of a global crisis, work isn’t normal, and we’re constantly distracted. Let’s face it, folks, our heads might not be in the game right now.
So take those stories and make them smaller, and give your brain (and your co-workers) a break.
