What is the best way to handle similar functionlaity in separate user stories / Product back Log Items?

Question

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?

Answer 1

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.

Answer 2

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.