File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Agile and Other Processes and the fly likes Help Defining a Story Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Help Defining a Story" Watch "Help Defining a Story" New topic

Help Defining a Story

Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15302

I sometimes still struggle with how certain stories should be structured or if they are supposed to be stories at all. I'm stumped again on the following:

Our design team has been busy implementing some new screens. Some of these screens are improvements to existing. Some are new. It is now time that we take these designs and wire them into the backend so they actually do something besides look pretty. So what are the stories that would encompass doing the wiring? For example, we have a few screens that deal with a customers account information (name, addresses, etc). All those screens were already there, just in a slightly different state/location. Now that they have been moved and improved, there is some wiring to do on the back end.

A story like "As a user I want to be able to manage my mailing addresses" is not right because, technically, they can do that now. So I'm a bit lost on what the story should be for that. One possibility that I am playing around with is:

"As a system I need to be wired to the new customer account mailing address designs"

GenRocket - Experts at Building Test Data
Junilu Lacar

Joined: Feb 26, 2001
Posts: 6529

Hi Gregg, sorry for the late reply. You might have already resolved this or may have just gone ahead with what you said by now. Anyway, here's what I usually do in situations like this:

First, if it doesn't fit, don't wear it. "As a system I need to be wired..." does not really feel like a user story and you probably had a nagging feeling about that. Usually, if it doesn't feel right or is awkward, I look for something else that feels better. That other thing would probably end up being one of two things: 1) create a task instead: "Wire up the new designs to the backend" or 2) Create an Engineering Story - "Integrate new designs with the back end" with tasks for each specific screen/design to wire up.

The nice thing about an Engineering Story is that you can put down as the benefit something like "so that we (the development team) can write automated integration/acceptance tests that exercise functionality from the UI through to the backend layers." The other nice thing about them is that we don't really feel bad about not following the "As a (role) I would like (capability) so that (benefit)" format.

Junilu - [How to Ask Questions] [How to Answer Questions]
Raja Pal
Ranch Hand

Joined: Jul 12, 2004
Posts: 92
I did further also suugest that you see why the new designs are useful, maybe they make the site more accessible, may be they reduce the number of clicks or reduce time taken in navigation/access. This way you can rewrite your story as:
As a CRM user I want a simpler interface or newer design that allows me to track mailing accounts faster/in 3 or less clicks so that I can <save time>

Java Pal - Your friend in technology and innovation...India.
Junilu Lacar

Joined: Feb 26, 2001
Posts: 6529

Good point Raja. I would tweak that though and reduce some details from the story statement and move them to the Conversation and Confirmation. That is:

(Following the 3 Cs format for user stories)

Card: As a User I want an easier way to manage my mailing addresses [so that I can save time and effort]

Conversation: Redesign the screens so that navigating to mailing addresses is easier/faster

Confirmation: Should take fewer mouse clicks to get to the mailing addresses than it does now
I agree. Here's the link:
subject: Help Defining a Story
It's not a secret anymore!