Communicating Design Intent

User Stories (I.N.V.E.S.T - Independent, Negotiable, Valuable, Estimatable, Small, Testable)
Book: User Stories Applied - http://powells.com/biblio/62-9780321205681-1

Ways to share design intent:

Pairing
Reviews
- Formal / Informal - Informal review may require little more than bullet points, and a whiteboard session.
- Design / Code
- Multi-Modal
- the moderator has an important role
IBIS (Issue Based Information System) - http://en.wikipedia.org/wiki/Issue-Based_Information_System
Models
- Not antithetical to agile development
- Types, formality, depth of models depend upon application / domain / project context
Capture design intent when found
- this is not always when the design / code was created
- for example: comments should be added when a section of code is found that at first glance looks questionable, but after questioning the author is clearly appropriate.
Refactor both design content (documentation), and source code.
Use a blog to capture design history of design decisions made
- Tag / Categorize the blog posts, for easier searching
- Good search is essential (google?)
- Entries might be added in response to issues that arise
- When documenting design decisions include
  - Design
  - Changes
  - Rationale
  - Other options considered
  - Options rejected or tried