Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Tell Good Stories

DZone's Guide to

Tell Good Stories

From the beginning of human culture we have told stories. They've always been important to educate and to create focus. Every feature we create should have a story. It explains and it guides.

· DevOps Zone ·
Free Resource

Do you need to strengthen the security of the mobile apps you build? Discover more than 50 secure mobile development coding practices to make your apps more secure.

Stories tell three things about a feature:

  • What it is

  • Why it’s there

  • Who it’s for

Stories do not tell how to implement a feature or even what it looks like. Stories are very high level.

Stories are placeholders meant to remind the Product Owner and developers to discuss a particular feature. It’s that discussion that replaces requirements and turns software development from blindly fulfilling specification into a discovery process where the Product Owner and the development team work together to find the best solutions to problems.

For example, a story for an online auction system might read as follows:

As a registered user, I want to bid on a started auction so that I may become the highest bidder.

Stories typically have this format:

As a _____ I want to _____ so that I can _____.

The first part of the story says who the story is for. The story is written in the first person: “As a registered user, I…” I have now included an initial constraint: “as a registered user,” which would have been defined in the previous story.

The next part of the story says what the story is about. “I want to _____” This is expressed as a desire from the user, again in the first person. It’s important here to focus on the goal of what we’re trying to achieve while giving us as little information as possible about how to achieve it. The goal is to state what the subject of the story wants.

The last element of the story states why the feature is wanted “…so that I can _____.” The so-that clause really speaks to why the feature is wanted and what the subject will get out of it.

These three pieces of information are key: who it’s for, what they want, and why they want it.

It’s easy to get lost in implementation details or the look and feel of a feature, and sometimes we lose sight of the bigger picture: Why we’re building the feature in the first place.

Stories keep us focused on what the feature is all about, who it’s for, and why they want it. It helps us build a better product for our customers.

Check out tips for blazing the way from agile to DevSecOps with security built into your mobile app toolchain.

Topics:
software development methodologies ,feature-driven development ,stories

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}