Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I think this question related not only to agile but to teamwork in general.

When we are working in a team and each member is working a user story to complete how to avoid creation of duplicate classes and conflict?

I mean if my user story require the creation of class A and also my team member need the same class and created the same (he may create it with slightly different name), how would we plan so that we move smoothly?

share|improve this question

migrated from May 4 '12 at 13:27

This question came from our site for professional and enthusiast programmers.

up vote 3 down vote accepted

User Stories are for communication with your customer. They are in customer's language and don't contain technical details like classes. When you start an iteration you should break down the User Stories in tasks. Tasks are in developer's language and can cover multiple stories.

share|improve this answer

I agree with @hansmaad. Agile is about communication. As in, actually talking to people on a regular basis. A user story is a reminder to have a conversation.

If you're doing XP, are you pair programming? Are you rotating pairs?

If you're doing Scrum, are you holding a daily standup?

Are you writing unit tests? Do you have customer acceptance tests? Are you practicing continuous integration?

There's still a risk of developers duplicating functionality, but it's not as high.

share|improve this answer
Downvoter - care to comment? – TrueWill Mar 8 '12 at 19:48

Your Answer


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.