User story for different devices

Last post 02:34 pm October 9, 2016
by Sergiy Pshenychnyy
6 replies
Author
Messages
02:49 pm October 6, 2016

Hi,

Do we need to write different user story for different devices? For example, footer design (view) is different from desktop and Tablet/mobile devices. Do we need specifically mention as separate user story?
How to handle such kind of request?

07:52 pm October 6, 2016

> Do we need to write different user story for different devices?

Why not ask yourself slightly different questions. What advantages would you have if they were written as different stories? Could value be evidenced earlier or perhaps more clearly to different stakeholders? Would feedback improve, and with better actionable metrics? If you batch the work into one story, what might be lost?

04:59 am October 7, 2016

There are no hard and fast rules to create a User Story. As we keep writing them, we keep getting better. Some things that can guide a user story creation are 1. it should be a small enough to be completed within the iteration as per the definition of done, 2. it should be very clear in its intent and business case 2. you should be able to test it . now let us look at your question again. if you think that providing a separate story for desktop and tablet/mobile devices is going to make it easy to achieve within an iteration, then you can do it. If on the other hand you feel that it would be an overkill, then by all means put it in the same story.

05:55 pm October 7, 2016

Hi,

When we find that there is potential to break user story into 2 or more small story, first question is how "independent" these stories are.
If it is same code, same information- means same value for end user - having single story with detail acceptance criteria for each device would make more sense to team.
If potential separate user stories are providing different information/value to end user or iterations/releases are based on devices supported by application, having two separate stories would help team to track and work upon.

08:02 pm October 7, 2016

If it is same code, same information- means same value for end user - having single story with detail acceptance criteria for each device would make more sense to team.

The one area I would caution you on is making the assumption that it is the same code, same information, and same end-user value.

What would be quicker - developing the functionality for one device, or developing it for multiple devices? Which "path" would get you to the feedback loop faster?

Often, developers focus on the "code" aspect (while I have the code open, it's easier for me to make multiple changes there). This approach doesn't recognize the tremendous value gained through the inspect and adapt cycle. The perceived gains from only opening the code once to make multiple changes can be quickly wiped away (and rework introduced!) if the solution presented is not to the end user's liking.

11:31 am October 9, 2016

Posted By Ian Mitchell on 06 Oct 2016 07:52 PM
> Do we need to write different user story for different devices?

Why not ask yourself slightly different questions. What advantages would you have if they were written as different stories? Could value be evidenced earlier or perhaps more clearly to different stakeholders? Would feedback improve, and with better actionable metrics? If you batch the work into one story, what might be lost?

02:34 pm October 9, 2016

There is no universal rule. If different user stories are more valuable to end user, then you should have multiple stories. But I'd not analyze user stories from implementation point of view. In my practice I use a simple criteria that works in most cases: if you need different acceptance tests for different devices then you should go with different user stories.