Skip to main content

User story for different devices

Last post 02:34 pm October 9, 2016 by Sergiy Pshenychnyy
6 replies
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.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.