The Agile Manifesto values working software over comprehensive documentation. In agile projects working software is the ultimate quantification of your project’s status. This may take some getting used to.

The signatories to the Agile Manifesto are not saying that technical documentation doesn’t have any value. Not at all; they’re simply emphasising the value of working software over comprehensive documentation. They’re saying that as working software should be the team’s goal, if producing detailed documentation for tradition’s sake is getting in its way, then it is time to adjust how much paperwork is produced.

“That is, whilst there is value in comprehensive documentation, we value working software more.”
-Signatories to the Manifesto for Agile Software Development

In addition, a number of the principles behind the Manifesto elaborate on this value:
- Working software is the primary measure of progress.
- [The team's] highest priority is to satisfy the customer through early and – continuous delivery of valuable software.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

How versus why
Finding the right balance between documenting and doing is an art that still causes much frustration in the lives of developers. And clearly not all documentation is bad. For example, sometimes end-user documentation is used as a criterion for ‘Done’. Sometimes it’s used to document decisions for team continuity. And documentation may even be needed for regulatory compliance. I’ve found it’s OK to leave the team to answer two simple questions: Is the documentation valuable? Is the team better off for writing it?

In my view this Manifesto value really addresses the project’s efficiency: The ‘how’ of the technicalities. The agile leader though, may be more interested in artifacts describing the project’s functional effectiveness: The ‘why’ of the business. This is because you are responsible for the software beyond its manufacture: Why you invested in it, and why it complements your broader business plan.

I’ve had great success using these documents to capture the business essence of an agile project. They convey stakeholder expectations of the project, the user needs the product will meet, and how the product will evolve once in the market. In my experience the benefit these artifacts bring to the team far outweighs the cost of producing them.

I strongly encourage Product Owners to produce these documents because they connect very deeply with the project through this process. Then, when the hard product calls need to be made, they’ll find the answers within them. And their confident, consistent decisions will earn Product Owners the respect of the other team members. Stakeholders will feel safe in their hands, too.

Business case
The purpose of the product business case is to set out: Stakeholder expectations; a mapping of the user needs to features to benefits; the proposed financial model; market opportunities identified; and, a product positioning statement. The product strategy outlined in this document should be consistent with the organisation’s business plan. (3 pages)

Vision
This is the chance to describe what the perfect product would look like—the outer bounds of market and functionality. The vision is derived from the business case and illustrates the problems that must be solved to reach the product’s goals, yet it should not be constrained by what is technically possible for the team. (3 pages)

Data sheet
This document distills out of the vision the principal features of the product, and their related benefits, in user language. If software was still sold off-the-shelf, this would be the promotional material printed on the outside of the box.(2 pages)

Overview
This artifact contains as many of the product’s features and related benefits that have been conceived at this point, in more detail than the data sheet, but still in user language. The overview, like the data sheet, still honours the product vision. Because it communicates how the Product Owner has interpreted the vision, when reading the overview team members often say, “Oh, I didn’t know you meant that. We’ll have to talk it through.” Then if proposed features and benefits need to be discounted for any reason, everyone is aware of the base off of which this is being done. (10+ pages)

Product backlog
With the previous documents in place the product backlog, which is a prioritised list of tasks described as user stories, becomes a doddle to produce.

Road map
So too with the road map: The release plan of future functionality is often a quarterly snapshot of the product backlog in a form that could be presented to internal and external stakeholders. Although some executives shy away from publishing the road map externally for fear of raising the market’s expectation of future functionality, I’ve found the benefits to outweigh the risks. The market appreciates that you have shared your plan for the product, and in turn it can participate more meaningfully in setting priorities.

I will elaborate on each of these documents in future posts, as well as provide templates of these documents for download. Be sure to look out for them.

Tagged as: agile, agile manifesto, cio, cto, leadership, management, product, product owner