Picture this: you have 10 months to build a fully-functional product, scalable to a million or more users, with a required set of features. You’ve got a kernel of a team, and enough resources to grow fast. Where do you start? And, oh, by the way, Dreamforce is coming up in two months, so you’d better have a demo ready to take on stage.
That’s where we found ourselves in September 2017 as we started building Philanthropy Cloud. We needed to get organized and get productive fast. Obviously, agile was the way to go, but how and where do you jump in and start?
Starting to dump bite-sized stories into an issue tracker felt totally wrong; there was still too much for us to think through and figure out as a team. We had to start at a higher level.
Instead of writing stories the “agile way” in the form of a feature-that-can-be-implemented-in-a-sprint, we stepped way back and started writing short, narrative documents that each describe a key element or concept of Philanthropy Cloud: nonprofits, employees, workplaces, donation flow, etc. We called these document “Epic Narratives” to emphasize the fact that they weren’t a “story” but a story.
Each Epic Narrative ranges in length from a few paragraphs to a few pages, and generally covers the background/concept of the feature, its key business rules, functions and how it relates to other aspects of the system. They’re much less than a technical specification, and deliberately written in plain English.
We’d write as much of one as we could given what we knew at the moment — which often wasn’t much — then move onto the next, looping back iteratively as we figured out more. We knocked out about 20 of these in a week, and that gave us enough shared context across the team for us to confidently start building a data model, architecting the key services and designing the front end.
As we rapidly hired new developers in those first few months, we didn’t have lots of technical documentation or formal onboarding materials, but we found that reading the set of Epic Narratives was typically enough to give new folks a solid overview of what we were building and enough context to confidently dive in and start working on something tangible. I was initially quite sheepish about this, because I wasn’t sure they were really detailed enough to be useful, but my reticence was quickly put to rest when a recently-hired colleague told me, “This is, hands down, the best new-developer documentation I’ve ever seen.”
A bit over a year in, we’ve written over 70 Epic Narratives of varying lengths and complexity, and they’ve become an integral part of our development practice. We’ve found that Epic Narratives are perfect for sharing not just with developers, but with internal and external business partners, as we work out how new features should behave.
As we’ve hired additional product managers, we’ve also found that they’re great artifacts for collaboration, review and alignment within our growing product team. They let us write down all of our shared assumptions and get the ideas and the scope right before we invest too much effort into writing individual stories. And, to the extent that we keep them up to date as we move through the design and development process (things always change — this is agile not waterfall!), they’re a nice summary of how the system works, and even better, they’re a great starting point for our documentation team.