Here are some things I add to each user story, as necessary, in the run-up to development:
- Background information
- Acceptance criteria
- Alternative scenarios
- Business rules
- Error handling
- Illustrations, UI mockups and designs
- API endpoints, data contracts
- Research data and user feedback
- Related product features
- Clear directions stating what technical approaches are acceptable
- Development standards
- Performance metrics
- Non-functional requirements
- Regulatory requirements
- Assumptions, constraints
- Anything else relevant
Now, before you burn me at the stake, hear me out. I’m fully aware this is the antithesis of Jefferies’ ‘placeholders for (in-sprint) conversations’ and somewhat at odds with Cockburn’s ‘walking skeleton’ concept. I’m not ‘agile ignorant’.
However, my professional work is within established financial services firms that predominantly use offshore development teams, and I can’t remember the last time I saw a software product built iteratively and informed by direct feedback from the most recently finished sprint. I’m sorry, but I just can’t.
So, I am afforded the luxury of collecting story details ahead of time, whilst remaining mindful not to overly solutionise, and the offshore developers are generally grateful to receive greater story context during refinement. However, do we regularly check in and discuss the boundary between my work and theirs.
Perhaps most interestingly though, the ‘narrating stories with details’ approach was first proposed in 2012 by Jeff Sutherland, one of the co-creators of Scrum, under the ‘Enabling Specifications’ [1] name, although it never did make it formally into Scrum.
The Scrum Book [2], an online library of Scrum literature and supporting patterns etc. (not to be confused with the Scrum Guide), explains the underlying rationale for Enabling Specifications as follows:
- Unexplored requirements cause unpleasant surprises
- early agile practice often blindly believed in deferring decisions and in having a ready, at-hand, on-site customer who could compensate for requirements shortfalls discovered during development
- it’s easy for the Product Owner to throw ideas into the Product Backlog and think “that’s good enough.”
- but a half-baked idea is still a half-baked idea even if we socialize and review it
- A user story isn’t even a full requirement: it is just a statement of some stakeholders’ identities and their motivation
- Most schedule surprises come from misunderstandings with roots in poor or poorly communicated analysis
- it’s important to move the uncertainty of analysis outside the Sprint — into the Product Owner process
Indeed, and I wholeheartedly agree.
I’m a huge fan of Enabling Specifications and draft them pretty much every day. However, they work best in the right context, which for me is offshore ‘feature factory’ Scrum teams, building line-of-business software or consumer-facing websites, for established companies in the UK. I carry no shame working this way, the opposite, in fact.
Lean Agile Training, whom I am not personally associated with, provides some excellent advice [3] for those wanting to practice the art of Enabling Specifications.
References
- Jeff Sutherland, Enabling Specifications: The Key to Building Agile Systems, 2012 (retrieved 19 Aug 2024)
- Scrum Book, Enabling Specification, retrieved 19 Aug 2024
- Lean Agile Training, Enabling Specifications, retrieved 19 Aug 2024