Use Case, Sequence and communication diagrams. However, for web based systems, Web UML class diagrams (MVC) is more useful from my exp

Sir,

Well, it depends on how you want to represent your overall system. To show specific users interactions to the system you can go for USE CASE (for specific user interactions within short details). Or else Activity is also applicable where you can add more details about the system you are going to develop. You can also refer to other online sources just for the clarifications (if needed) although at the end it always depends on how the system is developing. The link I added may help you. Thank You

http://stackoverflow.com/questions/61487/do-you-use-uml-in-agile-development-practices

 Good work syed. Glad to see the comments from someone from my ex.work place. I was attached with APIIT (2001-2006) and used to teach UML based modules there

Thanks for your comments. 

Few more answers I received from other sources.

1) The suggestion is to use UML to communicate designs within the team.. a shared language ; anyone taking a look at the diagram can understand the solution (faster than talking about it) and contribute quicker.

2) Use Case and Class diagrams are commonly used.

3) Some use tools to convert user stories to use case diagrams.

4) Use what you find helpful. If a UML diagram helps you visualize what you need to do, use it. If a whiteboard does the same thing, use that.

5) We use UML when you need to explain to other programmers how the user story works. You can just sketch out the interaction diagram and show which objects talk to which other ones.

6)  I find UML very useful as a simple communications medium between programmers. I feel Use case , Class and sequence diagrams are important

7) I'm an infrastructure architect and in case of problems or requested infra changes by agile teams I'm the most happy with sequence diagrams to communicate about and understand the software solution.

So diagrams may or may not needed for communication between people who can read code within an agile team but they are very useful for communication with others, like service managers and infra people who can't read code.

Dear Kapila,

I would say there is no strict rule in the use of which UML diagrams in agile development, however, this paper (attached) from Bernhard Rumpe can gives you some idea. Apart from what is written on books and papers, I always tried to understand the need of producing a certain diagram based on the Team experience around the subject. There are some Teams that are experienced and work together for a long time. So, they can communicate better to achieve an objective without documenting every single point of decision in the system. However, I always pushed them to produce a minimum  set of class/state/sequence diagrams to explain the problem and how they intend to solve the problem, when more complex stories come to the table. This was particulary useful to argue for estimatives (for example, using planning poker). 

Article Agile Modeling with the UML

Agile is about individuals and interactions over processes and tools. Formal tool-based representations tend to get in the way, except to document decisions that the team makes. Remember that documentation serves two purposes: to communicate, and to remember, and to a first approximation we use documentation only for the second purpose in Agile. Use cases can be a good way to document requirements decisions (though I much prefer an informal table approach à la Wirfs-Brock to the UML formalisms that most people use).

Also remember that Agile is about customer collaboration, so you want to be putting more effort into the human interface and less into artifacts that precede coding. You shouldn't need to be tool-heavy if you have a cross-functional, collocated team: replace documentation with face-to-face communication, chalkboard talks and PostIt®s.

Kabila above mentioned tools above to convert user stories to use cases. This misses the whole point of agile, and misses the point of human involvement and feedback.

Instead of sequence diagrams, engage the stakeholders in a CRC card exercise to dynamically walk through the scenarios.

UML isn't a good way to describe how a user story works. If you're in the user space, use a narrative for the contextualization and a user story for the role identification and motivation / goal. If you're into more detail, just write the code, and use that to describe what is going on. Agile is about working product, customer collaboration, and people — not tools, processes, nice pictures, proper formalisms, or documentation.

https://www.apptio.com/blog/7-steps-of-agile-system-analysis/