3Pillar Global’s SVP of Engineering, Jeff Nielsen, discusses how to outline the purpose of a project without getting bogged down by detail requirements work and slowing productivity.
Fred Brooks said that the assumption that we can satisfactorily specify in advance the software system that we should build is a flawed assumption. And if you believe that—if you believe that doing a lot of detailed up-front specification is not only impractical but actually harmful—you’ve got a little bit of a conundrum. Because if you don’t do any up-front requirements work, it’s going to be very hard to communicate to others about what you’re building, it’s going to be impossible to make commitments, and it’s going to be very difficult to get funding. You’re not going to get your project off the ground unless it involves just you working by yourself. On the other hand (as we’ve all experienced), as soon as you start trying to nail down the details of what we’re building and how it works, it’s very easy to get sucked into this alluring whirlpool of lots and lots of detailed requirements. So we need a way to find a happy medium. We need a way to talk about the boundaries and the outlines of what we are building without doing a bunch of detailed requirements work that, at best has to be changed, and at worst ends up being obsolete and waste.
What if we addressed this problem by telling each other stories? Stories are powerful. Our brains are hard-wired to hear, understand, interpret, and remember stories. Stories are sticky. So Kent Beck coined the idea of user stories: business people and technical people telling each other stories about what this future system that we’re going to build—this piece of software—would do, or what the software will do as someone uses it – a user story.
It’s a simple idea, but what it allows us to do is to tell stories at different levels of detail depending on where we are in a story lifecycle. When we are in some sort of release planning exercise or just up front, we can tell a whole bunch of really high-level stories: “what if this” and “imagine this” and “maybe this ending instead” or “how about this plot twist.” We’re not going to build all those stories, so there is no need to go into more than a little bit of detail—scrawl a few words on an index card, put a couple of notes in a planning tool. But because it’s a story, because it’s sticky, we will remember those discussions. And that’s probably enough to do some high-level estimates and some high-level plans.
Later on, as we sift through all the multiple ideas we’ve come up with for stories about how this system will work and we settle on a smaller number, we can go into some more detail about those stories (again, not too much) . . . until it’s time to actually build a handful of those stories when it’s the first day of an iteration or close to the first day of an iteration. Then it’s OK to go into a lot of detail: “Let’s get all the plot points of this story nailed down,” “What does the screen look like exactly?” “What are all the different exception paths?” or “What’s the happy path?” That’s the right time to finish filling in those details about a user story.
I call this progressive elaboration of user stories and I think of it as similar to interlaced images in the early days of the Internet. Remember the early days of the World Wide Web, when bandwidth was slow? When you would load a webpage with images, the images wouldn’t come in all at once. If it was an interlaced image, you would first see the outline of the image—just the bounding box. And then you would see a very pixelated version as a little bit of data trickled in. And then as more and more data arrived, the image would get more and more clear until finally it was the sharp image at the end. That’s what user stories allow us to do with requirements: define basic bounding boxes for the things we’re going to do—enough to plan, enough to estimate, enough to commit—and then we don’t need to fill in the details until we get close to the time that we’re actually going to build that user story.
That’s why this story construct—telling each other stories, elaborating a story—is such a powerful tool, and helps us to solve the agile requirements conundrum.