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 am using the TFS 2010 SCRUM template.

So, let's say I have these user stories:

As a user I want the ability to add contacts directly from the Partner page.

As a user I want the ability to add contacts directly from the Project page.

Design wise the contact forms should be the same and so should the functionality. So, if a user clicks the add contact button from either page, a pop up window will appear allowing the user to add a new contact. Should both those stories share similar tasks since the development and design are similar? Should I break up the features into separate stories?

Update: So, is it more acceptable to write this: As a user I want to add contacts from any area in the site so that I don't have to keep going back to a speicifc contact entry page.

Then I could supply the features we need for that story?

share|improve this question

2 Answers 2

up vote 6 down vote accepted

Should both those stories share similar tasks since the development and design are similar?

Yes.

Should I break up the features into separate stories?

No. Stories aren't features. They're stories.

You invent features that will support the stories. It's called "design".

You don't -- unthinkingly -- just code from a story.

First, you think. Then you do some design. Perhaps refactor existing code. Perhaps add, change or delete from existing code. Perhaps write new code.

But there's no silly one-to-one mapping between story and code.

You must still do real design work between story and code.


"As a user I want to add contacts from any area in the site so that I don't have to keep going back to a speicifc contact entry page."

No.

As a user I want to add contacts quickly and efficiently so that [ something goes here to show the value of adding contacts quickly and efficiently ].

Once you've shown the value of efficiency in the user story, you can write additional implementation information, like "A good feature would be adding contacts from any area of the site." This may lead to design considerations and other considerations for building this feature.

None of the implementation is in the story. It's okay to have footnotes and appendices and addenda and other material that goes with a story. But the story must be "pure" and state the proper business case and business value.

share|improve this answer
    
+1 Excellent answer, I have nothing to add. Many times I have seen Agile breakdown on a project when people lost the delineation between a user story and a requirement. I eventually ended up seeing stories like, "As a user, I should see that the First Name text field should be exactly 200px wide." –  maple_shaft Jul 7 '11 at 18:12
    
I realize that features are not stories, but should I create a story that supports the idea of opening a pop up window and define the featured of that window? –  DDiVita Jul 7 '11 at 18:12
    
@DDiVita. Still no. Stories aren't design. Design is separate from stories. Don't pollute your stories with design. Just do the design. If you want to write it down, that's a great idea. But that doesn't make it a story. –  S.Lott Jul 7 '11 at 18:14
    
@DDiVita: If your comment is that broad, it belongs in the question itself, not in any specific answer. Please update the question with any comment that applies to more than one answer. –  S.Lott Jul 7 '11 at 18:18
    
@S.Lott. I suppose, I could just shorten then whole statement to: “As a user I want to add contacts”. This is a requirement for the application so that in itself is the value, correct? Then, I can specify the different implementations of adding a contact to the system as features of that story? –  DDiVita Jul 7 '11 at 19:11

First, stories aren't Features - as S.Lott noted while I was still typing - stories define acceptance criteria for Features. So on the surface it would appear that both of these stories apply to the same Feature.

But I would go back to the customer who wrote these stories and ask them why -

As a user I want the ability to add contacts directly from the Partner page
SO THAT [business reason]

As a user I want the ability to add contacts directly from the Project page
SO THAT [business reason]

If the business reasons are the same, consider if it would be useful/necessary to be able to add contacts directly from any page, in which case there will only be one story (for the one Feature) - in other words, these two stories may imply a 'toolbar' or 'common menu' Feature, for capabilities available from every page.

But, if the business reasons are different, then you may have two underspecified features.

share|improve this answer

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.