Over a million developers have joined DZone.

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

The DevOps Zone is brought to you in partnership with Sonatype Nexus. The Nexus Suite helps scale your DevOps delivery with continuous component intelligence integrated into development tools, including Eclipse, IntelliJ, Jenkins, Bamboo, SonarQube and more. Schedule a demo today

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.

The DevOps Zone is brought to you in partnership with Sonatype Nexus. Use the Nexus Suite to automate your software supply chain and ensure you're using the highest quality open source components at every step of the development lifecycle. Get Nexus today

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.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

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

{{ parent.tldr }}

{{ parent.urlSource.name }}