0

I am working on a project and we really would like to try to use an agile software approach and are in the process of writing our user stories. This is new for us, although we have a lot of experience in writing successful software. My question relates to how to write stories when the product needs to run on multiple platforms...

Let's for arguments sake say our user stories were...

  • The user needs to be able to log in
  • The user can reset their password

Now this needs to work on several browsers, most likely several versions of browsers on both PC and Mac.

What has worked well for different teams in the past, do you test the story on all the platforms you expect to support or have you had success writing an extra user story like "must also work on Safari Version x.xx". I don't like the idea of the latter it doesn't have a good scope.

Another option might be to write the story repeatedly for each platform like this...

  • The user needs to be able to log in on Safari version x.xx
  • The user needs to be able to log in on Chrome version x.xx etc etc

Anyway, really just looking for some insight and interested to hear what has and has not worked for some other teams out in the community.

Thanks for sharing...

Steve Sheldon
  • 6,421
  • 3
  • 31
  • 35

5 Answers5

3

DoD is also a good way to do as Dave Hillier mentioned. Also, separate each story so they could be prioritized is also a good way too if each of browser compatibility has different priority level.

If it needs to be done in the same priority, and it's not that hard to make browser compatibility, I would do:

As a customer, I want to be able to login to the system, so that I can use the system

Exit criteria:
- xxxx
- yyyy
- be able to login on Safari, IE, Chrome, Firefox
Natty
  • 474
  • 4
  • 8
1

You could create a Definition of Done (DoD).

The DoD is usually a clear and concise list of requirements that a software Increment must adhere to for the team to call it complete.

In your DoD you should include the things that are mandatory for each story.

For example, when you implement a story, you probably want it to work on the most widely adopted browsers. Include the implementation and testing of a feature for each browser that you want support within your DoD.

You might decide that you want to add support for older browsers, but that is a much lower priority and can be done later. You can include that work separately as separate product backlog items (such as stories or bugs). They can then be prioritised as appropriate.

Those items can be written in the using a story template like, "As a user, I want". For example:

As a customer, I want to be able to log with IE8

As a customer, I want to reset my password from IE8

In the end, it is what your team decide will work best in your situation. It depends what your customer wants!

Dave Hillier
  • 18,105
  • 9
  • 43
  • 87
0

I would go with 4 stories like:

Users can Login with Safari
Users can login with IE
Users can login with Chrome
users can login with Firefox

You can then create acceptance criteria to test for the different relevant versions of each of the major platforms.

If you can, I would prefer to keep the stories as high level as possible. "The user needs to be able to log in" is flexible (as long as it isn't too large). Splitting the user story by browser feels a lot like mixing non-functional criteria and user stories.

Andrew Clear
  • 7,910
  • 5
  • 27
  • 35
0

" writing an extra user story like "must also work on Safari Version x.xx". I don't like the idea of the latter it doesn't have a good scope."

What you have dismissed with dislike is actually the better and correct way ! "it should also work on other browsers ..." should be an UAC and feature in the back of the story card.

This way you add BV for the customer and to your main story.

Another reason to support the UAC way as the correct way is 'elimination with the help of not recommended practices' - User stories should NOT be a laundry list.

user2347763
  • 469
  • 2
  • 10
0

I wouldn't create story per platform because US is "potentially shippable" unit which should bring value to end user.

Notice, there is nothing about how user should access feature, so ask yourself simple question - if it works on platform A but doesn't work on platform B, would you deliver this feature to the end user?

IMO it makes sense to create platform specific tasks for development and testing rather than US, you can't say that US is "done" if task is not finished.

Rrr
  • 1,747
  • 3
  • 17
  • 22