Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm setting up some requirements for a software extension and try to use user stories to describe what I want to achieve.

As a creator I want to add a new entry, to let users access it through the main page.

I have the idea of adding an entry via Drag&Drop. My company has some guidelines, to have every command always available via context menu and ribbon.

Should I split up my origin story into separate actions?

  • As a creator I want to drag a new entry onto the main page, to let users access it.
  • As a creator I want to create a new entry on the main page via ribbon, to let users access it.
  • As a creator I want to create a new entry on the main page via context menu, to let users access it.

That approach would result in at least three user stories per feature what won't feel comfortable to me.

I could add these expectations during the discussion, but then it seems like giving a "way-to-follow" for developers.

So how would I ensure that the required quality/user experience is achieved?

share|improve this question
add comment

3 Answers

up vote 4 down vote accepted

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.

share|improve this answer
add comment

It's my understanding that in Agile, a user story should be completed and tested in a single sprint.

With that in mind, I would not start by making separate stories, but just make one and outline the various pieces within it.

If after estimation (during planning) it's determined that the story will extend beyond a single sprint, split it into multiple with a common parent.

share|improve this answer
    
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. –  superM Jun 5 '13 at 14:34
add comment

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:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation

Cheers!

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.