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

Learn more about how CareerBuilder was able to resolve customer issues 5x faster by using Scalyr, the fastest log management tool on the market. 

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.

Find out more about how Scalyr built a proprietary database that does not use text indexing for their log management tool, allowing customers to search 1TB of data in under a second. 

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

Published at DZone with permission of David Bernstein, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}