Creating a user story for a back-end process

Question

I'm having trouble writing a user story for a back-end process.

Let say you are building a website that sells widgets. You have a page on the site where your site visitors can see all the details of the widget - pictures, videos, and detailed specifications.

All widget details are sourced from a third party provider. There is a scheduled task that picks up an XML file with the widget specifications, and related images/video and imports these into your database.

I have to write some user stories that capture all of this.

I can think of a story such as "As a widget researcher I can view the pictures, videos, and specifications for a widget". This would cover the building of the actual web page to view the details of a particular widget.

We also need a story for the back-end process that populates the database with all the widget data. It could be a task of the story above, but then it would be too big - it's probably a sprint or two of work in it's own right. When trying to frame this import from a user perspective, I just end up with the same user story, i.e. "As a widget researcher I can view the pictures, videos, and specifications of a widget".

Is there an alternative wording I could use for the import, frame it from a user perspective, and prevent confusion between the story for the import and the story for building the page to view the data itself.

Answer 1

There are a few ways I might write these stories.

Vertical slice (preferred)

Rather than implementing all of the front end in one story and all of the back end in another, you could try having multiple stories that do a bit of both. For example, the first you play might be:

As a widget researcher 
I want to see specifications of a widget 
So that I know if it's suitable for my use

This story might include getting the XML file with the specs, adding to DB and rendering on the page.

You could then introduce separate stories for the other media that do both the back end and front end together.

Manual import (3rd choice)

If doing the import of the specifications and front end was too big (I usually wouldn't accept a story that's bigger than half my velocity) you might consider a manual import of the data first:

As the widget display app
I want to be able to access specifications about widgets
So that I can display them to the user

This story would be a one off, manual data import that puts only the specs data in the DB. Once done, you then have some flexibility in what you do next.

You could then play a story to do the front end for displaying widgets.

After that, you can choose what is more important. If having the most up to date widget information on the site is critical, play a story to automate the data import. If the widgets don't change that often, it might be preferable to play a story to add one of the additional media types (again with a one off manual import).

I'd probably still include some sort of front end with this story. Perhaps just spit out the specs for a widget unstyled on the page so a non-technical product owner can still sign off without resorting to showing the the database!

Hybrid (2nd choice)

A better solution if vertical slices are too big might be to try a hybrid approach.

Keep the story from the vertical slice option (note, that story didn't have any implementation details about where the data comes from or is held) but change the acceptance criteria to not expect a scheduled import but put the data in the DB manually (as in the manual approach).

This allows you to still play a story that covers both DB and front end while not requiring you to automate the import process. As with the manual option above, you can then choose whether automating or adding additional media is more important to do first.