Purpose

The purpose of this document is to describe the processes related to product development at Kolab systems. This includes the following three parts:

1. Pre-Production (Sales, Product Management and Architecture & Design)
2. Production (Development)
3. Post-Production (QA, Release Management and Service)

The description will be detailed to a certain extent, but more details will be written out in appendix or in specific documents.

The Kolab instance of Phabricator is holding the following types of projects:

• Software Projects: most projects of this type is related to one or more source code management repositories. The Maniphest tasks are entered and associated with these software projects. Example: Copenhagen
• Role Projects: This type of project is providing workboards and workflow for a group of users with the specific role (members of the project). Example: Product Owners
• Sprint Projects: These projects provide workboards and workflow for the development team working the timeboxed sprint. #sprint_process 201516

Pre-Production

The Pre-Production process is an interaction between (corporate) Sales, Product Owners, and Architecture & Design. Product Owners collect input from all stakeholders, and describe the incoming requests from consumers of the Kolab Groupware product as user-stories, in Maniphest Tasks and make sure that they are associated with the Product Owners workboard. The workflow of the Product Owners workboard help the Product Owners facilitating the conversation with Architecture & Design and Quality Assurance. It consist of Incoming, In_Triage, Ready, and Done:

• Incoming When tasks has only just been created, and no other action has been taken yet, they are in this state.
• In_Triage This state is holding tasks in the process of clarification and prioritizing (Triage). This is where tasks are being exploded and separated into smaller more workable tasks. The actual Software Projects are determined and associated, technical details are added by Architecture & Design, and user-stories and test-cases are defined and approved by Quality Assurance.
• Ready Tasks in this state are ready to be associated with a sprint.
• Done Tasks has been through a sprint, they have been build and packaged, and the resulting packages are available to #release_management.

The Architecture & Design team evaluates the tasks technically during the triage, clarify the requirements with the Product Owners and separate them into workable sub-tasks. Every task must hold at least one test-case for a verifiable user story. These test-cases will be following the task all the way through the process and are a vital part of the deliverable measurement and documentation of the task and in the end release. To ensure the testability, Quality Assurance will evaluate the test-cases. If a test-case is not useful, Quality Assurance will require the task to be re-evaluated.

This evaluation is normally a part of the backlog grooming by sprint participants, but in such normal situations, the sprint participants are usually also involved with a mere one software project.

The evaluation is best done by a team in a single room. The Kolab development teams however are not in a single location, so the backlog grooming will have to happen on-line. Such grooming is done in preparation for sprints, so focussed on the future sprint backlogs, and not taking place as a general activity for the ~112 software project backlogs normally referred to as "product backlog" in Scrum terminology.

The Product Owners prioritize the tasks, and associates the tasks with the next sprint (by adding the next sprint to the task using hash-tags #sprint_desktop_next or #sprint_server_next).

This lists the tasks in a sprint backlog based on priority. It is then up to the sprint participants (currently still occupied with the current sprint, while the backlog for the next sprint is being filled) to ensure the backlog for the next sprint is appropriately groomed.

Production

Production starts with sprint planning. The team get together on-line, and look at the sprint backlog (the backlog for the #sprint_desktop_next or #sprint_server_next).

The Process Managers facilitate an evaluation of the tasks in the backlog in the order of priority. The needed effort is discussed. This evaluation results in the assignment of story points, and the tasks are assigned to a developer (if possible).

An amount of effort in every sprint should be reserved for interruptions.

In the beginning, the team will have difficulty figuring out exactly how to assign story points, and how many story points they can do in a sprint, but after just 2 sprints, it will improve considerably.

During the sprint, the Process Managers facilitate the daily standup call. In this call team members inform the rest of the team about the status of their work and which obstacles they encounter ("What did I do yesterday?" and "What do I plan to do today?"). It is the job of the Process Managers to work on and eliminate any obstacles if possible.

The sprint projects are configured with the sprint workflow; the states of: Backlog, Doing, Review, Done:

• Backlog is holding tasks that are selected for this sprint, but not being worked on yet.
• Doing is holding tasks that is actively being worked on by a developer (the assignee).
• Review is holding tasks where coding is done, but test case needs to be run [..and code review?].
• Done is holding tasks where the resulting code has been committed, and included test-cases has been successfully run.

As developers are working on tasks, these are being moved across the workflow columns in the sprint workboard.

In the end of a sprint, the Process Managers facilitate the sprint retrospective. The team get together on-line and show as much of the working software written during the sprint as possible by running through the included test cases [screen sharing facility or similar would be really good]. The status of the sprint documentation (burndown/burnup charts) is recognized and the velocity (the number of story points done in the sprint) is decided for the coming sprint.

Post-Production

When tasks are exiting a sprint in the status Done, there are one or more commits connected to each task, which resolve the issue (and successfully run through the included test-case) described in the task. These tasks are forwarded to Quality Assurance, by adding Quality Assurance to the task.

The relevant components are packaged, and packages are made available to Quality Assurance. If the packages pass Quality Assurance [simple workflow], they are handed over to #release_management, who will label them as releasable. They are however not released until all stakeholders (needs to be determined) agree to the release. The Product Owners facilitate this decision, and must

#support is added to the tasks for access to the test-cases. This makes it possible for #support to create and improve HowTo and FAQ documentation.

[?? maintain working VM from the latest releasable versions]

Glossary

Epic: The top umbrella item in the backlog. Is covering several stories and tasks. Epics can not be estimated as a complete entity. Only after estimating the smaller pieces together an estimation can be done.

Product Owner: The role responsible for the link between the customer and development. The product owner is creating the product backlog and prioritizing it.

Scrum master:

Developer:

The definition of Done: When the test-case for a certain task is being executed successfully, and the code resulting in the "fix" has been committed to git, the task can be moved to Done.

Project (in Phabricator): "Everything" is a project in the phabricator terminology. The projects are assigned to tasks (rather than the other way around) by adding the project hash tag to the task. We operate with the following types,

• Software Projects: One per software component or git repository (such as Copenhagen). They are associated with tasks related to this component. The software projects has no workflow. They lanes in the workboard describes the available versions in a forward directed manner.
• Role Projects: One per role in the process (such as Product Owners). When a person is given a role, they are added as members of the Role Project. Role projects has a workflow which is custom to the needs of the role.
• Sprint Projects: One per sprint (such as #sprint_server_201513). Tasks added to the Sprint Project is work that is planned for execution. Therefore the Sprint Projects has a workflow (described elsewhere in this documentation).

Review:

Story points: A number of points that describes the amount of effort needed to complete a certain task. The effort of a task is measured against the effort of the other tasks.

Releasable build: