User stories based on the existing design

Question

I'm currently working on a project that has already defined and approved design, and my task is to write user stories based on that design. There's one situation I keep facing and can't figure out the best approach.

Here's what I struggle with: we have screens with, let's say, several features in them - for example, there's a screen "Home" which contains two sections in it, my activity with some statistics and the list of recent deals. They aren't divided into tabs or something, activity on the top of the screen, and a list of deals below it.

The question is, should I separate them into different stories? Something like a separate user story for viewing my activity, a separate story for viewing the recent deals. Maybe it should be one user story for viewing the "Home" screen and view my activity/view recent deals as acceptance criteria?

If I had no design, I would separate them (since I've no idea how they will be grouped in the end and they seem to me as different features). However, I do have a design and I can't kind of view my activity without viewing the list of deals - they are on the same screen.

We have no Scrum Master, and nobody actually cares about "separate/not separate." Maybe I'm overcomplicating things and it really doesn't matter as long as the client is satisfied with the actual results? Any suggestions would be appreciated!

Answer 1

First, it is important to consider that, as you already have an up-front design and are simply implementing it, you are not practicing anything like Scrum or XP. This is not a value judgement - it's fine - just realize that the tool of user stories is not designed for what you're doing.

This, in turn, begs the question: Why do you want to use User Stories. The purpose of a User Story is to express a need of the customer so that your team has the freedom to develop the best implementation they can that fulfills that need. But you already have the implementation design, so you're sort of writing yourself into a paradoxical loop where you may have the user story expressing the need and any implementation the team picks that solves the need is fine as long as it's the implementation you've already defined, regardless of if they discover it solves the need.

And this leads me to the one case I can see for user stories here. You could go through an exercise in which you attempt to build user stories to challenge if your design in fact meets customer needs. This would be an odd use of user stories, but I suppose the results could be interesting. However, it doesn't sound like you are doing that, so the best thing I could suggest is to set user stories aside and build specs for the design for people to follow if fixed design is the approach your project is using.

Answer 2

First of all talk to the Product Owner and get their input. One of the good reasons you might want to write user stories for an existing design is to make sure you capture the "so that..." for each feature. It's likely that the team may be asked for changes to the design based on future feedback so if the motivation for design decisions is clear they will have the information on which to base their design decisions.

Assuming you can capture everything in story form, apply the INVEST criteria. Ultimately your backlog items need to be small enough to be done in a single iteration so you should probably take guidance from the whole team on that.

Answer 3

In a situation like this one, I perceive the value of these "stories" to be to capture an understanding of who the actual users of the system perceive themselves to be, what the system does for each of them, and exactly how they do it.

Don't assume that developers actually know this, particularly since they probably aren't the ones who built it.

Many "existing systems" have little twists-and-turns that are second nature to the system's users, but which would not at all be obvious to people who do not actually use the system every day. Workflows in such systems are sometimes convoluted, because of technical strictures that might have existed "back in the day." (For instance, many MS-DOS applications had to deal with "overlays," because memory was very limited and virtual-storage was not yet an available hardware feature. Their sometimes-puzzling menu structures today still reflect this, and might even have been carried forward verbatim in their first-generation replacements.)