DCH-RP:Documentation guidelines

WP5: Proofs of Concept

Scenarios

PoC Phase 1

PoC Phase 2

DCH Glossary

WP5: Proofs of Concept |

Documentation guidelines |

DCH Glossary

WP5 is using a number of tools to conduct its work. Many of the activities in Work Package 5 require documenting outcomes of some sort, and we need to find a way to document progress, outcomes and problems as a way of communication with other project and work package members. Usually, in a Scrum-managed project, team members are physically co-located to facilitate communication and mind-sharing. However, in projects such as DCH-RP this is impossible. Electronic documentation becomes paramount to communicate to team members efficiently and extensively.

This page will summarise how and where to document what.

WP5 Scrum backlog

The Scrum backlog is kept and maintained online in a Googledoc Spreadsheet. One caveat is that one must have a Google account in order to be able to edit the document (this is configurable, but has been set to prevent vandalism in case the sharing link accidentally got circulated to the public).

The backlog contains management and forecasting information. Its function is very much that of a dashboard to the Facilitator, the Product owners and the Project sponsors to get a quick overview of the state and shape of the work package. By nature, information in the backlog is therefore either outlined or transient.

The Product Team members will mainly use and edit the backlog for the following purposes:

1. Edit and add tasks in column E to the backlog (on sheets "Backlog PoC1" and "Backlog PoC2"
2. Organise a set of related tasks in Epics for overview purposes (sheet "Epics")
3. Document the sprint retrospectives as reminders (sheet "Sprint retrospectives").

As indicated, the backlog is organised in a number of "sheets" in the spreadsheet workbook; some of these have been protected from editing. This is not a measurement of distrust, but to prevent accidental changes that could change forecast and sprint management unintentionally.

Backlogs

The backlogs for Proofs of Concept 1 and 2 have an identical setup, hence their function and guidelines are discussed only once.

The backlog is the main coordination dashboard for the Product Team. In the backlog, the team:

• Adds and maintains tasks it has identified that needs being worked on (columns C and E)
• Agree and decide in which sprint which Task is planned to be worked on by the team(!) (column A)
• If applicable, identify to which "Epic" a task belongs (see epics below) (column B)
• Learn which Task has what priority - commonly , high priority tasks (5) are tackled before low priority tasks (1) are tended to (column D). The priority is not set by the team members, it is maintained by the Product Owner!
• Set and maintain "Points" for each task. A high number indicates a complex, complicated tasks while a low number indicates a very easy, straightforward action. Numbers of 20 or higher are used as indicators for "risky" tasks that need attention of the Product Owner and Project Sponsor, aided by the Facilitator.
• Maintain progress on the tasks setting status values during the sprints.

Note that comments should not be placed in the Google spreadsheet! When using the filters, Googledoc does not move the comments with the cells they were added to!

Points

Points are set as "guesstimates" - a mix between estimating and guessing, reflecting the fact that the more complex a task gets, the less accurate the effort estimation becomes. Although not recommended, team members tend to try and mentally map points to working days, or hours they expect to work on the respective task.

Task status

Task statuses are set according to the progress of work on it as follows:

<empty>

The task has not been started at all yet.

In progress

Someone has started working on this task and indicates that this task has been taken (so to avoid double work on the same task). As work on the task is progressing, the outcomes are documented elsewhere - not in the task!

Finished

The task has been finished. All required outcomes (usually documentation) is available and communicated, e.g. via Email to the WP5 mailing list.

Accepted

The Product Owner(s) set tasks from finished to accepted if they are satisfied with the outcome. In the sprint review meeting, the Project Team briefly demonstrates, indicates or otherwise explains the outcomes, and the Product Owner(s) decide on their "verdict".

Rejected

If Product Owners are not satisfied with the outcome, they decide to reject the task, so that the team can improve on it in the following sprint.

Wiki

The DCH-RP Wiki should be the place where to document semi-permanent and public information. Even though information in the Wiki changes over time, it is a convenient place to store even permanent information, and maintain it there.

The Wiki does not prescribe any structure of the documentation. It merely provides a notation convention and automatisms that allow easy linking of Wiki entries, as well as category trees or hierarchies.

Thus, the Wiki contributors decide the structure and contents of the Wiki!

DocDB

THe Document Database allows storing Presentations, Documents, etc. in a permanent and referencable way. Each "entry" in DocDB can host many individual documents, and provides access control nad version history. Hence DocDB is perfect for permanent document storage, i.e. Project Deliverables and Milestone documents.

Indico

Indico is a meeting organiser tool. It is good for announcing and organising meetings. It should be used to store:

• meeting entries, whether F2F or conference calls
• meeting agendas (either as text attachments or as timetable entries)
• meeting minutes (can be attached, too)

Each entry in Indico has a public reference similar to DocumentDB entries.

Discussion Forum

The Discussion Forum is - well, a discussion forum. It is used to discuss and generate knowledge. It is NOT used to store any documentation or permanent information. Forums can be very dynamic, and searching can get very confusing. So, information and knowledge gathered and generated in the Forum should be moved in an appropriate form to the Wiki.