User stories for functionality that cross-cuts multiple presentation modes? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the quest开发者_Go百科ion so it can be answered with facts and citations by editing this post.

Closed 5 years ago.

Improve this question

What's a good way to capture user stories when you have features that are common across multiple UI modes?

For example, imagine a commercial flight information system, something someone might use to answer the question "When is flight UA211 expected to land?"

As is often the case, the feature of providing schedule information is common underlying functionality, even though you might ask for it via a desktop web browser, a mobile browser (where you want to apply different style to make it more usable), and maybe even via SMS shortcodes.

Now, that certainly could be a single user story ("As someone meeting a traveller, I want to see flight arrival information so that I can be at the airport on time"). But that seems wrong (and would probably be an epic story, anyway).

You can make it separate user stories ("As a desktop user...", "As a smartphone user...", etc), which I've done in the past, and the team just knows to estimate the first one to include all of functionality, and the subsequent ones to estimate only UI implementation.

A third option is to make the underlying functionality a story isolated from the presentation layer, and then have UI stories: "As a flight info system front end, I want to get flight status information so that I can present it to the user", "As a desktop user, I want to see flight arrival... etc". But that seems artificial.

Thoughts?

dwh

---

I think the problem is that you are trying to tie the UI functionality to the backend too tightly.

For example, if you break it into a simple story:

A user may want to know the flight status given the flight number.

OK, now, given that you implement that, now you can look at which platforms will be calling this, as, one part of agile is not to over-develop, but in this case, if you have a business need to support mobile and desktop devices, then you should look at implementing this as a REST service, since that is the simplest solution for both to work with.

So the REST service solves the first story above.

Now, you will find that there are other specifics for each platform. For example, is there something on the phone that may already have the information, for example, did the traveller go to a trip site and already enter his info, then you may want to go there, assuming that the traveller is in the users contacts.

Or, if the user is just going to enter a flight number and that is it, then why not just do it as a webpage, as that is the simplest approach that supports both concepts. Then, if you have a url that supports GET, and outputs as HTML then you can easily display.

So, my first story was too simple, you may want to consider whether it is possible to return different types of data, so a user may want to have HTML, PDF, json or xml, but for each of these there should be a business need.

Unfortunately it is hard to answer your question as there are too many unknowns, which is why you are having a difficult time. If you ask the wrong question then you do have an epic, but if you can just break it down to a few simple stories then it becomes much easier to solve.

---

I would recommend the second option.

As you suggested, the first sounds like too much for a single story, and a story should always fit into a single iteration.

With the third option, the big problem is that you aren't delivering business value at the end of the story, which is generally a bad practice.

There are other ways you could split this work though. You could initially develop a very cut-down, barebones version which would work across all clients, and then refine each of them in subsequent stories.