Single Source of Truth

What is a Single Source of Truth?

A single source of truth is an agreed-upon shared location where information about requirements, defined processes, working agreements, and other important information can be easily found, used and updated as needed.

A good example of a SSOT is the stories (or PBIs) in the backlog. They define the intent of the product team and the specifics needed for the dev team to implement the desired functionality. Another SSOT is the code itself. In fact, the code is the ultimate SSOT. However, what does the team do for those pieces of information that do not belong in a work item or the code? A good example of a “process” SSOT is a WIKI. A wiki allows items to be updated as needed, commented upon, and have a revision history for accountability. WIKIs in ADO can be viewed by everyone on the team, as well as people outside the team. They can be searched. Etc.

Examples of Items for a process S.S.O.T.

• Team working agreement
• Definition of Ready
• Definition of Done
• User Acceptance Testing Checklist
• Release Checklist – what steps should be performed during a release.
• Etc.

Doesn’t an S.S.O.T. conflict with the Agile Manifesto?

The biggest argument I hear about implementing an SSOT is that it conflicts with one of the four principles of the Agile Manifesto: “Working Software Over Comprehensive Documentation” but I believe there is no conflict. I say this because a good S.S.O.T. is not comprehensive. In fact, a well designed S.S.O.T. should be simple enough to build quickly, use quickly, update quickly, and validate quickly. One of the reasons I push for the use of a WIKI as the location for your S.S.O.T. is because wikis are designed to meet all of the criteria I just mentioned. Let me give you an example:

I was working on a project where there was an issue with unzipped JAR files becoming corrupt during deployment. After discovering the issue, the team agreed to validate the JAR files after unzipping, but they didn’t have a way of reminding themselves to do this step. If they had a checklist for steps when they deployed, it would take about 45 seconds to open the checklist and add the step. Then they would be reminded about it during the next release. Also, if a new person took over the responsibility of releasing, the checklist would provide the steps to follow.