From Vision to Stories

A lot of the value I've been providing on my recent engagements has been in taking an idea and breaking it down to actionable stories in a backlog.

I've found myself struggling to consider time not spent writing code as a first-class part of my job. Dealing with feelings of guilt about not churning out code. But I'm also learning to value the importance of these activities. Though a bit tongue in cheek, one of my teammates once said to me:

The team actually works better if you don't code - so can you stop please?

What he meant was that I provide more value by ensuring the team aren't blocked by ambiguous and conflicting acceptance criteria.

High-quality stories -> Success

Anecdotally, I've seen a strong correlation between the quality/detail of acceptance criteria/story breakdown, and the speed and accuracy with which the team can deliver the work.

Some attributes of high-quality stories and AC:

  • Stories can be built (& provide value) independently
  • AC are consistently written (same tense, format, structure)
  • Dependencies between stories are called out
  • Out-of-scope items are called out
  • Mockups are included for complex UI
    • It is made clear that the mockups are just that - not the final product

Breaking it down

I generally start from an epic that represents the high-level feature we're talking about. Discussions with the product owner and other stakeholders start with the business objectives, and then delve down to how we might achieve these. We discuss constraints, business rules, mechanics of the feature, and explicitly call out what the feature won't do. Depending on the team I'm working with, we'll even go down into mocking up the UI and talking through how it would be used, so we're all on the same page.

From the high level ideas, rules and mechanics out of this, we start to structure some acceptance criteria for the epic.

From these high-level statements, I then break the epic down into stories that make sense to build on their own. I try to make them cumulative where possible - rather than implement every facet of a feature in one go, find the most basic use case for that feature. Implement that first, as its own story - then create other stories that add extra functionality.

Writing Acceptance Criteria

I use the format "The user can achieve XYZ goal", and clarify any details of mechanics at the shallowest level of detail possible - we're documenting objectives, rules and intent here.

I don't use the format "The system should" or "The system will" - the AC are statements of what is possible when the story is considered complete. They should be a script usable by any testers (automated, technical or business) to determine this completeness.

I also specifically reference any attachments/mockups by name as part of the AC. If a mockup isn't referenced by the acceptance criteria, it shouldn't be there.

Managing dependencies

When breaking things down, aim for the smallest story that can be built, tested, and provide value in isolation. This necessarily introduces dependencies between stories, and that's okay - as long as they're called out. The benefit here is that the Product Owner is granted the ability to prioritise according to what's most valuable to them, rather than artificially constraining them to larger stories because "it's easier to develop it all in one go".

It's also important to explicitly call out what's not in scope - especially when we've got interrelated stories that are building upon one another. If something's part of the larger feature to be built, add a link over to the story that will implement it.

Example

As a Store Manager  
I want to view viable rostering combinations for my staff  
So that I can maximise available staff on each shift

Description  
-----------
This is the foundation story for rostering. Staff have their [own availability](https://link.to/the-staff-availability-story), and are categorised by function. It allows the Store Manager to drill down into one proposed combination of staff functions, and understand the viable rostering combinations given staff availability.

The functionality for this page will be enhanced further by adding the ability to [consider parental car-pools](https://link.to/the-car-pool-story) and [consider fair work restrictions](https://link.to/the-fair-work-story).

Definitions  
-----------
- Roster: An instance of a rostering combination on a specific date
- Viable Roster: a roster with adequate staff availability to fill each function required
- Non-viable Roster: a roster where one or more staff functions cannot be filled due to inadequate staff availability

AC  
--
- The user can select a specific rostering combo to view
- A date range can be specified to constrain dates for rostering
  - By default, start- and end- dates are the boundaries of the current month
- All potential rosters within selected date range are listed in ascending date order down the page
  - Each potential departure displays a staff list (functions and who will fill them), indicating whether the roster is viable or non-viable based on staff availability
  - This could potentially show up to 31 rosters (full month date range)
- A toggle can be used to "show non-viable rosters"
  - Toggle defaults to off
  - When off, only viable rosters are displayed (see mockup "Roster Planning - Viable Only")
  - When on, both viable and non-viable rosters are display (see mocup "Roster Planning - Include NonViable")

Depends on  
----------
- [WORKITEM-650](https://link.to/workitem-650) implements the ability to enter staff availability, and must be built before this story.

Out of scope  
------------
- Though shown in the mockups, this story doesn't include "Consider fair work restrictions" functionality. This will be developed in [WORKITEM-765](https://link.to/workitem-765).
- Does not include ability to see parental car-pool options which will optimise staff rostering for maximum transport efficiency. This will be developed in [WORKITEM-767](https://link.to/workitem-767).