Agile Software Development Review

Agile Modeling (AM) is a practice-based methodology for effective modeling and documentation of software-based systems.   At a high level AM is a collection of best practices, depicted in the pattern language map below (click on the practice for information).  At a more detailed level AM is a collection of values, principles, and practices for modeling software that can be applied on a software development project in an effective and light-weight manner. 

A detailed agile SDLC.

1. Agile Requirements Modeling in a Nutshell

Figure 1 depicts the Agile Model Driven Development (AMDD) lifecycle, which depicts how Agile Modeling (AM) is applied by agile software development teams.  The critical aspects which we're concerned about right now are initial requirements modeling, iteration modeling, and model storming.  The fundamental idea is that you do just barely enough modeling at the beginning of the project to understand the requirements for your system at a high level, then you gather the details as you need to on a just-in-time (JIT) basis.

Figure 1. The AMDD lifecycle.

1.1 Initial Requirements Modeling

At the beginning of a project you need to take several days to envision the high-level requirements and to understand the scope of the release (what you think the system should do).  Your goal is to get a gut feel for what the project is all about, not to document in detail what you think the system should do: the documentation

can come later, if you actually need it.  For your initial requirements model my experience is that you need some form of:

1. Usage model.  As the name implies usage models enable you to explore how users will work with your system.  This may be a collection of essential use cases on a Rational Unified Process (RUP) project, a collection of features for a Feature Driven Development (FDD) project, or a collection of user stories for an Extreme Programming (XP) project. 

2. Initial domain model.  A domain model identifies fundamental business entity types and the relationships between then.  Domain models may be depicted as a collection of Class Responsibility Collaborator (CRC) cards, a slim UML class diagram, or even a slim data model.  This domain model will contain just enough information: the main domain entities, their major attributes, and the relationships between these entities.  Your model doesn’t need to be complete, it just needs to cover enough information to make you comfortable with the primary domain concepts.  

3. User interface model.  For user interface intensive projects you should consider developing some screen sketches or even a user interface prototype.

What level of detail do you actually need?  My experience is that you need requirements artifacts which are just barely good enough to give you this understanding and no more.  For example, Figure 2 depicts a simple point-form use case.  This use case could very well have been written on an index card, a piece of flip chart paper, or on a whiteboard.  It contains just enough information for you to understand what the use case does, and in fact it may contain far too much information for this point in the lifecycle because just the name of the use case might be enough for your stakeholders to understand the fundamentals of what you mean.  Figure 3, on the other hand, depicts a fully documented formal use case.  This is a wonderful example of a well documented use case, but it goes into far more detail than you possibly need right now. If you actually need this level of detail, and in practice you rarely do, you can capture it when you actually need to by model storming it at the time.  The longer your project team goes without the concrete feedback of working software, the greater the danger that you're modeling things that don't reflect what your stakeholders truly need.

The urge to write requirements documentation should be transformed into an urge to instead collaborate closely with your stakeholders and then create working

software based on what they tell you.

 Figure 2. A point-form use case.

Name: Enroll in SeminarBasic Course of Action:

Student inputs her name and student number System verifies the student is eligible to enroll in seminars. If not eligible then the student is informed and use case ends. System displays list of available seminars. Student chooses a seminar or decides not to enroll at all. System validates the student is eligible to enroll in the chosen seminar.  If not eligible, the student is asked to choose another. System validates the seminar fits into the student’s schedule. System calculates and displays fees Student verifies the cost and either indicates she wants to enroll or not. System enrolls the student in the seminar and bills them for it. The system prints enrollment receipt.

 Figure 3. A detailed use case.Name: Enroll in SeminarIdentifier: UC 17

Description:Enroll an existing student in a seminar for which she is eligible. Preconditions:The Student is registered at the University. Postconditions:The Student will be enrolled in the course she wants if she is eligible and room is available. Basic Course of Action:1.        The use case begins when a student wants to enroll in a seminar.2.        The student inputs her name and student number into the system via UI23 Security Login Screen.3.        The system verifies the student is eligible to enroll in seminars at the university according to business rule BR129 Determine

Eligibility to Enroll. [Alt Course A]4.        The system displays UI32 Seminar Selection Screen, which indicates the list of available seminars.5.        The student indicates the seminar in which she wants to enroll. [Alt Course B: The Student Decides Not to Enroll]6.        The system validates the student is eligible to enroll in the seminar according to the business rule BR130 Determine Student

Eligibility to Enroll in a Seminar. [Alt Course C]7.        The system validates the seminar fits into the existing schedule of the student according to the business rule BR143 Validate

Student Seminar Schedule.8.        The system calculates the fees for the seminar based on the fee published in the course catalog, applicable student fees, and

applicable taxes. Apply business rules BR 180 Calculate Student Fees and BR45 Calculate Taxes for Seminar.9.        The system displays the fees via UI33 Display Seminar Fees Screen.10.     The system asks the student if she still wants to enroll in the seminar.11.     The student indicates she wants to enroll in the seminar.12.     The system enrolls the student in the seminar.13.     The system informs the student the enrollment was successful via UI88 Seminar Enrollment Summary Screen.14.     The system bills the student for the seminar, according to business rule BR100 Bill Student for Seminar.  15.     The system asks the student if she wants a printed statement of the enrollment.16.     The student indicates she wants a printed statement.17.     The system prints the enrollment statement UI89 Enrollment Summary Report.18.     The use case ends when the student takes the printed statement.Alternate Course A: The Student is Not Eligible to Enroll in Seminars.A.3. The registrar determines the student is not eligible to enroll in seminars.A.4. The registrar informs the student he is not eligible to enroll.A.5. The use case ends.Alternate Course B: The Student Decides Not to Enroll in an Available SeminarB.5. The student views the list of seminars and does not see one in which he wants to enroll.B.6. The use case ends.Alternate Course C: The Student Does Not Have the PrerequisitesC.6. The registrar determines the student is not eligible to enroll in the seminar he chose.C.7. The registrar informs the student he does not have the prerequisites.C.8. The registrar informs the student of the prerequisites he needs.C.9. The use case continues at Step 4 in the basic course of action. 

 Requirements Artifacts

Because there are several different types of requirements, some or all of which may be applicable to your project, and because each modeling artifact has it’s strengths and weaknesses, you will want to have several requirements modeling artifacts in your intellectual toolkit to be effective.  Table 1 summarizes common artifacts for modeling requirements, artifacts that are described in greater detail in the article Artifacts for Agile Modeling.  The type(s) of requirement that the artifact is typically used to model is indicated as well as a potential “simple” tool that you can use to create the artifact (the importance of using simple tools was discussed earlier in the section Some Philosophy).

Table 1.  Candidate artifacts for modeling requirements.

Artifact Type Simple Tool Description Acceptance Test

Either FITNesse Describes an observable feature of a system which is of interest to one or more project stakeholders.

Business rule definition

Behavioral Index card A business rule is an operating principle or policy that your software must satisfy. 

Change case Either Index card Change cases are used to describe new potential requirements for a system or modifications to existing requirements. 

CRC model Either, Usually Behavioral

Index cards A Class Responsibility Collaborator (CRC) model is a collection of standard index cards, each of which have been divided into three sections, indicating the name of the class, the responsibilities of the class, and the collaborators of the class.  A class represents a collection of similar objects, a responsibility is something that a class knows or does, and a collaborator is another class that a class interacts with to fulfill its responsibilities.  CRC models are used, during requirements modeling, for conceptual modeling which explores domain concepts and high-level relationships between them.

Constraint definition

Either Index card A constraint is a restriction on the degree of freedom you have in providing a solution.  Constraints are effectively global requirements for your project.

Data flow diagram (DFD)

Behavioral Whiteboard drawing

A data-flow diagram (DFD) shows the movement of data within a system between processes, entities, and data stores.  When modeling requirements a DFD can be used to model the context of your system, indicating the major external entities that your system interacts with.

Essential UI prototype

Either Post It notes and flip chart paper

An essential user interface (UI) prototype is a low-fidelity model, or prototype, of the UI for your system – it represents the general ideas behind the UI but not the exact details.

Essential use case

Behavioral Paper A use case is a sequence of actions that provide a measurable value to an actor.  An essential use-case is a simplified, abstract, generalized use case that captures the intentions of a user in a technology and implementation independent manner. 

Feature Either, Usually Behavioral

Index card A feature is a “small, useful result in the eyes of the client”.  A feature is a tiny building block for planning, reporting, and tracking.  It’s understandable, measurable, and do-able (along with several other features) within a two-week increment (Palmer & Felsing 2002).

Technical requirement

Non-Behavioral Index card A technical requirement pertains to a non-functional aspect of your system, such as a performance-related issue, a reliability issue, or technical environment issue. 

Usage scenario

Behavioral Index card A usage scenario describes a single path of logic through one or more use cases or user stories.  A use-case scenario could represent the basic course of action, the happy path, through a single use case, a combination of portions of the happy path replaced by the steps of one or more alternate paths through a single use case, or a path spanning several use cases or user stories. 

Use case diagram

Behavioral Whiteboard sketch

The use-case diagram depicts a collection of use cases, actors, their associations, and optionally a system boundary box.  When modeling requirements a use case diagram can be used to model the context of

your system, indicating the major external entities that your system interacts with.

User story Either Index card A user story is a reminder to have a conversation with your project stakeholders.  User stories capture high-level requirements, including behavioral requirements, business rules, constraints, and technical requirements. 

An important thing to remember is that although there are several artifacts that you can potentially use for requirements gathering that doesn’t mean that you need to use all of them on any given project.  You should understand when it is appropriate to use each artifact, knowledge that enables you to follow the practice Apply The Right Artifact(s) to your situation at hand.

The underlying process often motivates artifact choice.  On the home page I indicate that AM is used in conjunction with another software process, such as eXtreme Programming (XP) or the Unified Process (UP), whose scope is the full lifecycle.  Very often the underlying process will prefer certain primary requirements artifact(s), in the case of XP user stories and for the UP use cases, an issue that you must consider when requirements modeling.  See the articles  AM and XP and AM and UP for further details.

Some Potential Analysis Models

Are the artifacts created taking an agile approach to analysis any different than the ones created as the result of traditional analysis?  In a way they are.  They are in fact the same types of artifacts, a use case diagram is a use case diagram after all, but the way in which they are created are different.  The artifacts are created following the principles and practices of AM, they are just barely good enough and are often discarded so as to travel light.  

Table 1 lists common artifacts used during analysis modeling and suggests a simple tool with which you could create such an artifact.  It is interesting to note that this list is meant to be representative, a more thorough list is presented in the article Artifacts for Agile Modeling and in the book Agile Modeling.

Table 1.  Candidate artifacts for analysis modeling.

Artifact Simple Tool

Description

Activity Diagram Whiteboard UML activity diagrams are used during analysis modeling to explore the logic of a usage scenario (see below), system use case, or the flow of logic of a business process.  In many ways activity diagrams are the object-oriented equivalent of flow charts and data-flow diagrams (DFDs).

Class Diagram Whiteboard Class diagrams show the classes of the system, their inter-relationships (including inheritance, aggregation, and association), and the operations and attributes of the classes.  During analysis you can use class diagrams to represent your conceptual model which depict your detailed understanding of the problem space for your system.

Constraint definition

Index card A constraint is a restriction on the degree of freedom you have in providing a solution.  Constraints are effectively global requirements for your project.

CRC model Index cards A Class Responsibility Collaborator (CRC) model is a collection of standard index cards, each of which have been divided into three sections, indicating the name of the class, the responsibilities of the class, and the collaborators of the class.  Like class diagrams, CRC models are used during analysis modeling for conceptual modeling.

Data flow diagram (DFD)

Whiteboard A data-flow diagram (DFD) shows the movement of data within a system between processes, entities, and data stores.  When analysis modeling a DFD can be used to model the existing and/or proposed business processes that your system will support.

Entity/Relationship (E/R)   diagram (data diagram)

Whiteboard E/R diagrams show the main entities, their data attributes, and the relationships between those entities.  Like class diagrams E/R diagrams can be used for conceptual modeling, in many ways E/R diagrams can be thought of as a subset of class diagrams.

Flow chart Whiteboard Flow charts are used in a similar manner to activity diagrams.

Robustness diagrams

Whiteboard Robustness diagrams can be used to analyze usage scenarios to identify candidate classes and major user interface elements (screens, reports, ...).

Sequence diagram Whiteboard Sequence diagrams are used to model the logic of usage scenarios.  Sequence diagrams model the flow of logic within your system in a visual manner, enabling you to both explore and validate your logic.

State chart diagram Whiteboard State chart diagrams depict the various states, and the transitions between those states, that an entity exhibits.  During analysis modeling state chart diagrams are used to explore the lifecycle of an entity that exhibits complex behavior.

System use case Paper A use case is a sequence of actions that provide a measurable value to an actor.  A system use case includes high-level implementation decisions in it.  For example, a system use case will refer to specific user interface components – such as screens, HTML pages, or reports.  System use cases will also reflect fundamental architectural decisions, such as the use of ATMs versus cell phones to access your bank account.  

UI prototype Whiteboard A user interface (UI) prototype models the user interface of your system.  As a part of analysis modeling it enables you to explore the problem space that your system addresses in a manner that your project stakeholders understand.  Remember, the user interface is the system to most people. 

Usage scenario Index card A usage scenario is exactly what its name indicates – the description of a potential way that your system is used. 

Use case diagram Whiteboard The use-case diagram depicts a collection of use cases, actors, their associations, and optionally a system boundary box.  When analysis modeling a use case diagram can be used to depict the business functionality, at a high-level, that your system will support.  It can also be used to depict the scope of the various releases of your system via the use of color or system boundary boxes.

Design Throughout The Lifecycle

Figure 1 depicts the generic agile software development lifecycle.  For the sake of discussion, the important thing to note is that there is no design phase, nor a requirements phase for that matter, which traditionalists are familiar with.  Agile developers will do some high-level architectural modeling during Iteration 0, also known as the warm-up phase, and detailed design during development iterations and even during the end game (if needed). 

 Figure 1. The Agile SDLC.

Architecture Design

Architecture provides the foundation from which systems are built and an architectural model defines the vision on which your architecture is based. The scope of architecture can be that of a single application, of a family of applications, for an organization, or for an infrastructure such as the Internet that is shared by many organizations.  Regardless of the scope, my experience is that you can take an agile approach to the modeling, development, and evolution of an architecture.

1. Every system has an architecture. BUT, it may not necessarily have architectural models describing that architecture. For example, a small team taking the XP approach that is working together in the same room may not find any need to model their system architecture because everyone on the team knows it well enough that having a model doesn’t provide sufficient value to them. Or, if an architectural model exists it will often be a few simple plain old whiteboard (POW) sketches potentially backed by a defined project metaphor. This works because the communication aspects of XP, including pair programming and Collective Ownership, negate the need for architecture model(s) that need to be developed and maintained throughout the project. Other teams – teams not following XP, larger teams, teams where people are not co-located – will find that the greater communication challenges inherent in their environment requires them to go beyond word-of-mouth architecture. These teams will choose to create architectural models to provide guidance to developers as to how they should build their software. Fundamentally, the reason why you perform architectural modeling is to address the risk of members of your development team not working to a common vision.

2. Architecture scales agile.  This is true of traditional techniques as well.  Have a viable and accepted architecture strategy for a project is absolutely critical to your success, particularly in the complex situations which agile teams find themselves in at scale.  Scaling issues include team size, regulatory compliance, distributed teams, system complexity, and so on.  An effective approach to architecture enables you to address these scaling issues.

2. Architecture Throughout the Lifecycle

 The reality is that the development of architecture is very hard, an effort that is key to your success, and one that you’re not going to get right from the start.  An iterative and incremental approach addresses the risk of an inadequate or inappropriate architecture by developing it a bit at a time, and only when you need it.

 There are four basic strategies for organizing agile teams at scale:

1. Architecture-driven approach.  With this strategy you organize your subteams around the subsystems/components called out in your architecture.  This strategy works well when your architecture is of high quality (it's loosely coupled and highly cohesive) and the interfaces to the subsystems have been identified before the subteams really get going (the interfaces will evolve over time, but you want to get a good start at them initially).  The challenge with this strategy is that it requires your requirements to be captured in a way which reflects the architecture.  For example, if your architecture is based on large-scale business domain components then a requirement should strive to focus on a single business domain if possible.  If your architecture is based on technical tiers -- such as a 3-tier architecture with user interface (UI), business, and data tiers -- then requirements should focus on a single tier if possible.

2. Feature-driven approach. With this strategy each subteam implements a feature at a time, a feature being a meaningful chunk of functionality to your stakeholders.  I would apply this strategy in situation where the architecture exhibits a lot of coupling AND where you have sophisticated development practices in place.  The challenge with this approach is that the subteams often need to access a wide range of the source code to implement the feature and thereby run the risk of collisions with other subteams.  As a result these teams sophisticated change management, continuous integration, and potentially even parallel independent testing strategies in place (to name a few).

3. Open source approach.  With this strategy one or more subsystems/components are developed in an open source manner, even if it is for a single organization (this is called internal open source).  This

strategy is typically used for subsystems/components which are extensively reused by many teams, for example a security framework, and which must evolve quickly to meet the changing needs of the other systems accessing/using them.  This strategy requires you to adopt tools and processes which support open source approaches.

4. Combinations thereof.  Most agile teams at scale will combine the previous three strategies as appropriate. 

6. The Agile Architecture Process

Figure 3 depicts the process for architecture activities on an agile project.  The core architecture team is responsible for envisioning the initial architecture then bringing it to the rest of the project team for feedback and subsequent evolution.  To avoid an ivory tower architecture the members of the core architecture team will take active roles on the various subteams on the project, communicating the architecture to the subteams and working with them to prove portions of the architecture via concrete experiments.  From the point of view of the development subteams the architects act as consultants whose expertise is the corporate architecture as well as active members of the subteam.  The core architecture team should view the development subteams as their customers, as project stakeholders for their architecture, customers that will need help from them and who will have new requirements that necessitate change to the architecture.  In short, the core architecture team should actively work with their project stakeholders, in this case the development subteams.

 Figure 3. Agile architecture process.

The core architecture team will find that they need to get together occasionally to evolve the architecture as the project progresses, negotiating changes to the architecture and updating their architectural model(s), if any, as appropriate.  These meetings will be frequent at the beginning of a project and will be needed less and less as

the architecture solidifies.  It will be common for members of the development subteams, who may not be members of the core architecture team, to attend some meetings to present information, perhaps they were involved with some technical prototyping and have findings to share with the architects.  The best meetings are short, often no more than half an hour in length, and are often held standing up around a whiteboard – everyone should come prepared to the meetings, willing to present and discuss their issues as well as to work together as a team to quickly come to resolutions. 

7. Requirements-Driven Architecture

Your architecture must be based on requirements otherwise you are hacking, it’s as simple as that.  The practice Active Stakeholder Participation is critical to your success when it comes to identifying architectural requirements – remember, requirements come from project stakeholders, not developers. Good sources for technical architecture requirements will include your users and their direct management as they will often have some insight into technical requirements and constraints.  Operations staff will definitely have requirements for you pertaining to your deployment architecture.  The best sources for business-oriented requirements are exactly who you would expect – your users, their managers. Senior management within your organization will have insights that may lead to potential change cases for your system.

As you would expect the practices Apply The Right Artifact(s) and Create Several Models in Parallel apply to your architectural requirements effort.  When you are working on the technical aspects of your architecture you will want to base it on technical requirements, constraints, and possibly change cases. Similarly, when you are working on business aspects of your architecture, potentially identifying software subsystems or business components, you will likely need to focus on essential use cases or user stories that describe critical usage requirements and potentially the key business rules applicable to your system. 

A common mistake that architecture teams (or for smaller projects the architecture owner) will make is to ignore existing and pertinent artifacts, such as network or deployment diagrams that describe your organizations existing technical infrastructure, enterprise-level business models (use case models, process diagrams, workflow diagrams, corporate business rules, and so on), or corporate deployment standards (for workstations, branch offices, etc.) that your system is expected to conform to.  Yes, the existing artifacts may be out of date or simply not apply to your effort, but you should at least make an effort to examine them and take advantage of the existing work wherever possible.  A little bit of reading or discussion with the right people is likely to save you significant effort later on.  In other words, don’t forget to reuse existing artifacts whenever possible.

An important concept to understand about architectural modeling is that although it typically occurs early in your project it never occurs first.  Fundamentally, you will always invest time identifying some requirements first.  Anything else is hacking, and hacking certainly isn’t agile. 

13. Take a Multi-View Approach

Agile Modeling's Multiple Models principle advises you to recognize that because modern systems are complex that you will need to consider a range of views in your architecture.  Although they take different approaches, a multi-view strategy is a fundamental concept in modern architectural frameworks such as the Zachman Framework, TOGAF, 4+1, and so on.  Each of these frameworks have very good reasons for their choice of views, they all seem to work well in practice, they can all be approached in an agile manner, so my advice is to review your options and pick the architectural framework which best reflects the culture of your organization.  My goal here isn't to propose yet another architecture framework, it is to make you aware of them and their underlying concepts.  Figure 4 overviews the views and concerns which software/system architects need to be concerned about.

Figure 4. Architectural views and concerns.

14. How Does This Work? 

The architectural approach that I’ve described is markedly different that what a lot of organizations are currently doing today.  Table 1 compares and contrasts the architectural practices that are commonly found in many organizations with their agile counterparts.  Clearly, there’s a big difference.  The agile approach works because of its focus on people working together effectively as a team.  Agile Modeling recognizes that people are fallible, that they aren’t likely to get the architecture right to begin with and therefore need the opportunity for acting on feedback from implementation efforts.  When agile architects are productive members of the development team, and when the development team has been involved with the architectural efforts to begin with, then comprehensive documentation isn’t needed by them, the navigation diagrams are sufficient (granted, when this is not the case documentation, hopefully minimal, may be required).  Architecture reviews aren’t needed because the architecture is being proved through the concrete feedback of architectural prototyping/spikes and because people can see the architecture evolve because your models are displayed publicly for everyone to see.  Agile architects have the courage to focus on solving today’s problem today and trusting that they can solve tomorrow’s problem tomorrow (Beck, 2000), and the humility to recognize that they cannot accurately predict the future and therefore choose not to overbuild their architectures. 

  Table 1. Comparing Common and Agile Architectural Practices.

Common Practice Agile Practice

Architects are held in high esteem and are often placed, or even worse place themselves, on pedestals

Agile architects have the humility to admit that they don’t walk on water

Architects are too busy to get their hands dirty with development

Agile architects are active members of development teams, developing software where appropriate and acting as architectural consultants to the team

Architecture models are robust to enable them to fulfill future requirements

Agile architects have the humility to admit that they can’t predict the future and instead have the courage to trust they can solve tomorrow’s problem tomorrow

The goal is to develop a comprehensive architecture early in a project

You evolve your architecture incrementally and iteratively, allowing it to emerge over time

Well-documented architecture model(s) are requiredTravel light and focus on navigation diagrams that overview your architecture, documenting just enough to communicate to your intended audience

Architecture model(s) are communicated only when they are “suitable for public consumption”

Architecture model(s) are displayed publicly, even when they are a work in progress, to promote feedback from others

Architecture reviews are held to validate your model(s) before being put into use

Architectures are proved through concrete experiments

Model Type Simple Paper Whiteboard Software

Acceptance Test       FITNesse

Business Rule   Card   Word Processor

Change Case X Card   Word Processor

Class Responsibility Collaborator (CRC) model X Card    

Constraint   Card   Word Processor

Contract model       As Needed

Data Flow Diagram (DFD)     X CASE

Domain Model     X CASE

Essential/Abstract Use Case X Flip chart X Word Processor

Essential/Abstract User Interface Prototype X Flip chart    

Feature X Card   Spreadsheet

Free-Form Diagrams X   X Diagramming Tool

Flow Chart     XDiagramming or CASE

Glossary   Card   Word Processor

Logical Data Model (LDM)       CASE

Network Diagram       Diagramming

Object Role Model (ORM) Diagram     X  

Personas X Flip chart   Word Processor

Physical Data Model (PDM)       CASE

Robustness Diagram     X  

Security Threat Model     X  

System Use Case       Word Processor

Technical Requirement   Card   Word Processor

UML 2 Activity Diagram     X CASE

UML 2 Class Diagram     X CASE

UML 2 Communication/Collaboration Diagram     X  

UML 2 Component Diagram     X CASE

UML 2 Composite Structure Diagram     X  

UML 2 Deployment Diagram     X CASE

UML 2 Interaction Overview Diagram     X  

UML 2 Object Diagram     X  

UML 2 Package Diagram     X CASE

UML 2 Sequence Diagram     X CASE

UML 2 State Machine Diagram     X CASE

UML 2 Timing Diagram     X CASE

UML 2 Use Case Diagram     X CASE

Usage Scenario X Card   Word Processor

User Interface Flow Diagram (Storyboard)     X Diagramming

User Interface Prototype     XPrototyping tool or IDE

User Story X Card   Spreadsheet

Value Stream Map     X  

 Agile documents:

Maximize stakeholder investment

Are concise

Fulfill a purpose

Describe information that is less likely to change

Describe “good things to know”

Have a specific customer and facilitate the work efforts of that customer

Are sufficiently accurate, consistent, and detailed

Are sufficiently indexed

Valid reasons to document:

Your project stakeholders require it

To define a contract model

To support communication with an external group

To think something through