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?
What is the best way to handle similar functionlaity in separate user stories / Product back Log Items?
agile;scrum;team foundation server;stories
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.