Q:

Do Agile projects use abbreviated defect reporting?

I'm accustomed to relatively rigid defect reporting, something like this.
Steps to reproduce:
1. Access customer manager for user Test01
2. Check "User must change password" and click Apply
3. Access login page
4. Enter user name and password
5. Click Login

Expected results:
6. Site displays user profile page (see use case 21.1.2)

Actual results:
6. Site displays error page (see attached screen shot)

I recently joined an Agile project where the defect reports look more like this:
Can't sign on with user Test01, see screenshots

In my many years of development experience, I've found that the longer defect reports serve numerous purposes, e.g. it succinctly communicated the precise problem and avoids any sort of judgmental language, and clearly represents the defect as a departure from a required behavior, rather than allowing the QA engineer to make up defects for behaviors that "seem" wrong.
Agile methodology de-emphasizes the importance of documentation.  Instead we're encouraged to pick up the phone and talk to each other.  
Is this a valid application of Agile principles?  Or should defect reports be fairly verbose even when we're trying to be agile?

A:

If encouraging people to frequently interrupt each other just because of plain laziness is considered Agile, then I have to admit that my understanding of Agile is seriously broken. 
A sufficient problem description is not a (potentially superfluous) product documentation, rather it is a distinct collection of all facts necessary to efficiently reproduce and solve the issue. 
If the description in whatever form is sufficient, fine. If that's not the case, close it as "Not reproducible, reopen if new infomation becomes available" - with one exception:  If you feel the need to investigate because of the potential risks uncovered by the issue, you may consider biting the bullet and follow-up. You don't want (e.g.) a security issue left unfixed just because of a poor description.

A:

"Agile" does not mean you have no rules and processes - just that you should try to get by with as little as possible (but no less, to paraphrase the Einstein quotation). The Agile Manifesto expresses this as "Individuals and interactions over processes and tools".
In your case that means you should discuss this with your colleagues. Explain the benefits you see in having more structured bug reports, and try to find a solution that everyone can work with.
Maybe some of your colleagues have good reasons for not wanting to require more structured reports (for example, not scaring off users who want to report bugs, or because they found that the structure never quite made sense) - or maybe they just never thought about it.
You'll only find out by asking :-).

