“Wiki’s” Can Revolutionize Your Project Management

At Arke we handle our requirements a bit differently than others. When working with us on a website project you will hear us talk about the “Project Specifications Wiki” .

What is a Project Specifications Wiki?

The Project Specifications Wiki, or just “Wiki”, contains all the documentation needed to build your website. It contains everything from the environment URLs and Business Requirements to the Implementation and Technical Requirements. This is where you will find the specific functionality and interactions of each feature of the site.

Why a Wiki?

There are several reasons why keeping the specifications in a Wiki makes sense.

• Documentation at the Ready: Documentation becomes part of the process, and not an afterthought.
• No Requirement Searching: If the details are all in your tickets, then once tickets are closed, they can be hard to find in the backlog – not to mention that as requirements change during a project, there may be several conflicting user stories. The Wiki gives you a single place to look to as the source of truth.
• No Duplication of Requirements: With a Wiki, requirements that pertain to multiple places within the site/project can be documented once and then be easily referenced as needed.
• It is the Requirements Hub: The Wiki contains the Business Requirements, Implementation Requirements and Technical Requirements in a single place. It also contains links to 3rd party resources and to the design files.
  
  

What about the Backlog?

The backlog still exists. The Project Specifications Wiki and the Backlog will work together. The Wiki will link to the appropriate backlog tickets, and the tickets will link to the requirements. The tickets are very lean, with a high-level description and acceptance criteria. The Wiki provides all the details needed to complete the full scope of the ticket.

What does this all look like?

The organization of the Backlog and the Wiki (particularly the Implementation Requirements) will somewhat mimic each other. In the Backlog there will be Features, and each Feature will be broken down into individual User Stories, which in turn, can be further broken down into Tasks by the developers. In some cases, Features may be grouped into larger Epics. The organization of the Wiki has a similar hierarchy as shown in the example below.

User Stories
The User Stories will include a short description of the work to be done, the specific intent of the scope of the ticket, a link to the respective Wiki page with the details, and acceptance criteria. Below is an excerpt of a User Story.

Project Specifications Wiki | Implementation Requirements
Each page of the Implementation Requirements will describe a specific component of the website/product. It will include screenshots, links to original design files, a breakdown of the component or work to be done for each element of the component, any content management requirements and technical implementation requirements. Below is an excerpt of the Wiki page that describes the work for the User Story shown above.

The Project Specifications Wiki tells the story, while the Backlog allows us to track the work . Keeping the meat of the information in the Wiki means that at the end of a project there is no need to sift through the closed tickets, or write complicated queries, to find the tickets necessary to explain how a feature works. When someone needs to understand how an aspect of the site works, they can quickly find everything they need in the Wiki.