In it’s most generalized definition, developer artifacts are any of the “byproducts” of the project development cycle, from initial planning documentation to the compiled software itself. Having a collection of artifacts works as a roadmap, allowing maintainers to go back and explore the project in all its phases. High value artifacts also provide end-users and product maintainers with information on how to work or manage the product.
Consider the name, artifacts. If your development project, from start to initial release to maintenance, is an archaeological dig, then artifacts are what is left behind to discover, allowing future coders and project maintainers to learn not only the details of the project itself, but the context surrounding those details.
And like in dig sites, some artifacts are more valuable than others. A user story outlining the purpose of a feature that has already been built and is running properly may be of interest to a project maintainer, but does not provide the maintainer with any information regarding keeping the codebase up-to-date and application running. In this instance, comments within the code, output from previous tests, and written documentation are going to provide the maintainer with more value and context for whatever problem he or she is trying to tackle.
Regardless of the project’s current state, and an artifact’s individual value to the entire roadmap, these artifacts do provide team members and clients internal visibility on the intent, goals, and issues of the creation and maintenance of a project.
Common Artifacts and Agile Terminology
Artifacts can span across the entire space of a project. Although not commonly categorized, artifacts tend to fall into three general types of information: The code and results from the code, artifacts created during the project management process, and documentation.
Code-related artifacts can include (but are not limited to):
- Compiled code: The code itself, compiled and in a state ready to run
- Test and code output: Information and logs generated during testing and QA periods
- Setup scripts: The scripts that prepare the environment to run the software
- Test suites: Sets of test cases intended to run against the program during testing phases
- Objects generated by end-users: These are collected data objects logged when a user interacts with the software
These artifacts are of primary interest to the developers and engineers working on the technical aspects of the project and project maintenance, and also provides a technical history of issues and project growth.
Project manage artifacts can include (but are not limited to):
- Acceptable criteria: The basic requirements given by the client or project owner
- User stories: High-level requirements detailing the specific needs of the project; more in-depth and task-focused than criteria
- Acceptance tests: Descriptions of expected software behavior
Documentation artifacts can include (but are not limited to):
- Class diagrams: Static diagrams of the system
- Walkthroughs: Written guides taking testers, QA or other teams through the application, top to toe
- End-user documentation: Documentation intended for the clients or end-users to assist in software usage
- Internal documentation: Documentation intended to assist employees maintain, fix and otherwise alter the application
By no means are these the only artifacts generated during a project’s lifetime, and not all artifacts even necessarily be readily available to everyone, even internally. Of the above types of artifacts, it’s code and documentation that most concern software developers and maintainers, and documentation that assists clients or end-users user the product. These are generally considered deliverables and are the final parts of the product that are delivered, both internally and externally. These artifacts are best stored on wiki-based systems like Confluence, Intranets, and shared folders wherein those who need access to the artifacts have can.
Artifacts provide everyone, at all levels of the project, a better understand of the software development process it went through. And while not everyone needs stakeholder notes or old user stories, artifacts provide a history of the project, and aid in supporting it through its lifetime.