The law of raspberry jam — the more it spreads, the thinner it gets — definitely applies to “agile software development.” “Agile” is ubiquitous and nearly meaningless at the same time. You don’t learn much about how a company actually operates from hearing that it’s “agile.”
This isn’t a new claim, and it shouldn’t be controversial. OG agile manifesto signatories and prominent programmers have pointed this out already:
I was among the seventeen middle-aged white guys who gathered at Snowbird, Utah. We were there because we shared common beliefs about developing software…since that Snowbird meeting, I haven’t participated in any Agile events…Because I didn’t think that any of these things were in the spirit of the manifesto we produced.
–Dave Thomas, “Agile is Dead”
Agile is a very broad tent. You can find people who say, ‘I’m doing agile’. And then you talk to another guy who says, ‘I’m doing agile.’ And they’re doing the exact opposite things.
– DHH, “Is TDD Dead? Part 5”
Jim Rumbaugh took me aside and he said, “Kent, in 10 years, you’re not going to recognize what people have done to [extreme programming]…It’s out of your control now and its all going to hell.”
– Kent Beck, “Is TDD Dead? Part 5”
User stories also suffer from the law of raspberry jam. There are deep differences between the user stories Mike Cohn describes and the “imposter” user stories people typically describe. Here I want to catalogue some of those differences.
My intent in pointing out these differences isn’t to say “we’re doing it wrong.” There are good reasons to diverge from agile practices. I simply want us to be more clear about what user stories actually are, according to the person who invented them.
Clarity on user stories is important given that pointing out that something is “the agile way” is often sufficient to shut down conversation about other — possibly better — ways of running a software project. It can make sense to opt for battle-tested solutions to project management problems, even if those solutions aren’t as optimal as ones we’d work out from first principles, but it’s downright silly for us to choose solutions that are merely posing as the battle tested ones articulated by Cohn and other agile leaders.
Here are some important facts about user stories as Mike Cohn originally described them in User Stories Applied.
User stories shouldn’t take less than half a day
“…it’s good to have stories that can be coded and tested between half a day and perhaps two weeks by one or a pair of programmers.”1
I can’t tell you how many times I’ve felt silly creating a “story” in jira because it seemed like the effort to create it was more than the effort of fixing the issue. This silliness can’t be justified in the name of “user story” best practice.
User stories are not meant to document the details of how software will work
[User stories] represent customer requirements rather than document them…the details are worked out in the Conversation.2
There’s wisdom in hashing out detail in conversation (and tests). Odd how often I’ve heard, told others, or been told myself to add more detail to a story instead of just talking to people.
Story points can be measured in whatever units you want, including time
A nice feature of story points is that each team defines them as they see fit. One team may decide to define a story point as an ideal day of work. Another team may define a story point as an ideal week of work. Yet another team may define a story point as a measure of the complexity of the story.3
People love to talk about how story points should be measured in “complexity.” Cohn himself prefers to use an idealized unit of time. I think this is a better than using complexity, a concept that is slippery at best.
Sprint planning w/ stories involves a design phase
While there is no upfront design phase, agile processes are characterized by frequent short-bursts of design. Disaggregating stories into tasks — which can only be done with at least a minimal design in mind — is one of these short bursts of just-in-time design that replace a waterfall’s upfront design phase.4
Almost everywhere I’ve worked that uses user stories has also done more upfront design than is suggested by Cohn here. We’re missing an opportunity to defer design work until stories are broken into constituent tasks.
User stories should be independent
avoid introducing dependencies between stories. Dependencies between stories lead to prioritization and planning problems5
Jira has a feature that I always look for: it allows you to mark one story as depending on another. I’ve even pushed for the companies I’ve worked out to use the feature more often. Turns out the need for this feature is a smell.