3 Answers
3

I think its wrong to divide the user-story into 3 pieces. You mentioned that every command should be accessible from 3 places. That can be pre-assumed in the user stories for new commands (or explicitly mentioned in every such user story).

If you need to divide it because development will implement those as separate tasks, IMO something isn't designed well in the back-end.

A user story as a rule represents a complete feature. And I wouldn't consider the feature complete unless the new command is accessible from every place required. Moreover, I would include accessibility in the command development user story itself.

As what comes for achieving the required quality, that's what testing is done for.

I would argue that a user story should be completed during a single sprint. That is usually true for sub-tasks, but the user-story should be logically complete. And it is often hard to have both complete and single-sprint stories. When I need to choose, I'd go for complete stories.
–
superMJun 5 '13 at 14:34

What does your team think? For some features, maybe a single story will be fine. For other, more complicated functions, you may need three (or more) stories (One for command line, one for Web UI, one for Android, etc.). Stories should not be written in a vacuum, include your technical minded folks as well and the process will flow much smoother. At the beginning of each iteration, spend some time going over the stories with the team, and they will let you know if multiple stories are needed, or if one is fine.

Do not assume anything for a story, over-arching story requirements can often be overlooked, conflict with the story, or cause other complications. Spend your time focusing on the end user experience, ideally create test cases/scenarios to accompany the story. This will help guide the team to create the experience you want.

To assure quality you stop by to visit with the team, or even better sit with the team to be available anytime a question comes up. The more time you are able to spend with the team, the more satisfied you are likely to be with the quality. I'm not saying to micromanage every activity of ever minute, but rather to be available as discussions are taking place and questions come up. Ask to see the product as it is being developed, don't wait for an iteration review or showcase. In the end, Agile is about producing a quality product, that is why principles 1 and 2 are: