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.

Transcription:

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

Shift Your Mindset to Find Product Success 3Pillar CEO David DeWolf spoke on the importance of seeing software development through the lens of product at the recent “Product Matters” event in I...
Flexing Your (Underused) Creative Muscle On this episode of The Innovation Engine, we talk about how to start flexing what is likely an underused muscle, if you're like 98 percent of the popu...
Where Are the Female Leaders in Tech (& How Can We Attr... On this episode of The Innovation Engine, we examine the dearth of female leaders in technology and look at ways we can mentor and encourage more fema...
Microservice & Serverless Architectures – Is Eith... On this episode of Take 3, we explore microservices and serverless architectures - what they are, why microservices have gained so much in popularity ...
5 Cost Saving Strategies When Using AWS Amazon Web Services, or AWS, offers reliable and scalable cloud computing services. More and more companies are realizing the benefits and are migrati...

SUBSCRIBE TODAY


Sign up today to receive our monthly product development tips newsletter.