Agile Best Practices: SVP of Engineering Jeff Nielsen on “User Stories”

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.

Access this video on both Vimeo and YouTube.


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.

Jeff Nielsen

Jeff Nielsen

SVP of Engineering

Jeff Nielsen is 3Pillar’s SVP of Engineering. In this role, he oversees the delivery of technology services to all 3Pillar clients. Jeff is responsible for all development processes in the company and manages numerous global client-based engineering teams.

Prior to 3Pillar, Jeff was the CTO and SVP of Delivery at the Santeon Group, where he ran their global software development initiatives and their agile coaching practice. At Santeon he provided executive-level coaching to federal agencies and Fortune 100 commercial clients making large-scale transitions to agile. As Head of Engineering at TrapWire for three years, he oversaw more than 50 production releases of the company’s flagship SaaS product. Jeff was also Vice President/Chief Scientist at Digital Focus, pioneering their use of agile methods in early 2001. Jeff has worked with a number of organizations – from startups to multibillion-dollar firms – over the course of more than a decade to help them improve their software development processes.

Jeff holds M.S. and M.A.Ed. degrees in Computer Science and Instructional Technology from Virginia Tech and a Bachelors in Music from BYU.

Leave a Reply

Related Posts

Interviews from Industry Summit 2017: the Product Conference On this special double episode of The Innovation Engine, the 3Pillar team interviews many of the speakers who took the stage at Industry Summit 2017. ...
Designing the Future & the Future of Work – The I... Martin Wezowski, Chief Designer and Futurist at SAP, shares his thoughts on designing the future and the future of work on this episode of The Innovat...
The 4 Characteristics of a Healthy Digital Product Team Several weeks ago, I found myself engaged in two separate, yet eerily similar, conversations with CEOs struggling to gain the confidence they needed t...
Recapping Fortune Brainstorm Tech – The Innovation Eng... On this episode of The Innovation Engine, David DeWolf and Jonathan Rivers join us to share an overview of all the news that was fit to print at this ...
4 Reasons Everyone is Wrong About Blockchain: Your Guide to ... You know a technology has officially jumped the shark when iced tea companies decide they want in on the action. In case you missed that one, Long Isl...