There are several common misconceptions that people seem to have regarding 
modeling on an XP project.  The three most common misconceptions are that you 
don’t model on an XP project, that you don’t document on an XP project, or that 
if you do model your only options are the modeling artifacts of the UML.  

Too much focus on the word “extreme”.  XP’s name is both one of its greatest 
strengths its greatest weaknesses.  Because of the name when some people hear 
XP’s advice to travel light, to reduce the amount of documentation that you 
create and maintain, that they instead translate it to “create no documentation 
at all”.  That’s extreme, right?  Or they’ll hear XP’s advice to use simple 
modeling techniques such as user stories and CRC cards and somehow translate 
that advice to “you don’t model at all.”  That’s extreme, right?  Sigh. 


Modeling is Part of XP
User stories are a fundamental aspect of XP and artifacts such as Class 
Responsibility Collaborator (CRC) cards are common to XP efforts.  User stories 
provide a high-level overview of the requirements for a system -- they are 
reminders to have a conversation with your project stakeholders regarding their 
requirements -- and are used to as a primary input into estimating and 
scheduling, and drive the development of acceptance test cases.   CRC cards are 
used to explore structure, perhaps for conceptual modeling to understand the 
problem domain or for design to work through the structure of your software.  
User stories and CRC cards are both models, see the Artifacts for AM essay, so 
therefore modeling is clearly a part of XP.  XP developers will also create 
sketches, often on a whiteboard or a piece of paper, whenever user stories and 
CRC cards aren’t the best option.  In Extreme Programming Explained (Beck, 
2000), the first book written about XP, Kent Beck includes hand-drawn sketches 
of class diagrams and other free-form diagrams.  The bottom line is that 
modeling is a fundamental aspect of XP, something that I explore in detail in 
this essay. 

  
Documentation Happens
Documentation is also an important part of XP.  Ron Jeffries (2001b) offers the 
following advice:

“Outside your extreme programming project, you will probably need 
documentation: by all means, write it.  Inside your project, there is so much 
verbal communication that you may need very little else.  Trust yourselves to 
know the difference.” 


The need for documentation on an XP project is reduced by several of its 
practices.  First, because of test-first development and a focus on acceptance 
testing there is always a working test suite that shows that your system works 
and fulfills the requirements implemented to that point.  For the developers, 
these tests act as significant documentation because it shows how the code 
actually works.  When you think about it, this makes a lot of sense.  When you 
are learning something new do you prefer to read a bunch of documentation or do 
you look for source code samples?  Many developers prefer to start at source 
code samples, and the test suite provides these samples.  Second, XP’s focus on 
simplicity and practice of refactoring result in very clean and clear code.  If 
the code is already easy to understand, why invest a lot of time writing 
documentation to help you to understand it?  This applies to both internal and 
external documentation – why add comments to code that are already clear and 
unambiguous?  If the code isn’t so, then refactor it to improve its quality or 
as a last resort write documentation.  Even though some development 
environments make it easy to include documentation in your code, Java’s Javadoc 
utility is such an example, you only want to invest in documentation when it 
makes sense to do so and not just because it is easy.



What confuses many people regarding XP and documentation is that XP doesn’t 
specify potential documents to create during development.  This is unlike the 
Unified Process (Kruchten, 2000; Ambler, 2001b) which suggests a slew of 
potential project artifacts.  Instead, the suggestion is to work together with 
your project stakeholders in an environment of rapid feedback and trust them to 
determine the things that they need, not just documents but any type of project 
enhancements (Jeffries, 2001b).  Once again, you need to have the courage to 
trust the people involved with the project.  In the essay Agile Documentation I 
discuss a collection of documents that you may choose to create and provide 
advice for when to consider creating them.


One of the greatest misunderstandings people have about XP regards concept of 
traveling light – many people believe that it means you don’t create any 
documentation, but nothing could be further from the truth.  What traveling 
light actually means is that you create just enough models and documentation, 
too little or too much puts you at risk.  As I suggest in Agile Documentation a 
good rule of thumb to ensure that you’re traveling light is that you shouldn’t 
create a model or document until you actually need it – creating either thing 
too early puts you at risk of wasting your time working on something you don’t 
actually need yet. 


An important thing to understand about documentation on an XP project is that 
it is a business decision, not a technical one.  This is consistent with AM’s 
philosophy regarding documentation, discussed in Agile Documentation.  Jeffries 
(2001b) says it best:


“If there is a need for a document, the customer should request the document in 
the same way that she would request a feature: with a story card.  The team 
will estimate the cost of the document, and the customer may schedule it in any 
iteration she wishes.”