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"
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.
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.