Scrum of scrum process

This wiki page describes the implementation of the scrum of scrum process in the openETCS project. This description is subject of ongoing work as the process may be changed or refined to best fit the needs of the project. The overall goal of the process is to gather and focus available resources of the project members to work on the most urgent issues, i.e. to maximize the benefit for the overall the projects goals. To allow project wide acceptance for the scrum of scrum process and minimize management overhead the implementation is chosen lightweight, e.g. without introducing additional tools.

Product backlog

• The product backlog is implemented via the issue tracker of the dedicated product backlog repository.
• The product backlog consists of prioritized user stories. Priorities are integers in the interval [1...1000], with 1000 representing the highest priority. Note that the absolute value is of minor interest, priorization is only needed to classify backlog items by importance.
• Priorities are captured in the title of each user story respectively issue. Example: US-Data-Dictionary Prio: 500 represents a user story with priority 500. The reason to capture the priority in the title is to make priority changes traceable, as the text of github issues may be changed without leaving any trace.
• The labels Ready, In Progress, and Deferred are used to capture the state of user stories. Note that closing an issue is equivalent to the state Done.
• A user story may only be moved to the state Ready when:
  • A priority has been assigned.
  • The scope is clearly defined and distinguished from other user stories in the states Ready or in Progress.
  • The criteria for reaching the state Done are clear.
• Every project member is eligible to propose user stories.
• New user stories shall remain in the state (respectively column) Inbox until they have been reviewed by the team in a grooming session.

Waffle

• The backlog can be visualized as a scrum board with help of the free web based tool waffle. The use of waffle is completely optional, as it does not provide any additional information. However, waffle provides a more user friendly and intuitive way to display the information in the backlog.
• When using waffle the backlog items of the same category (e.g. Ready) should be ordered by priority with the highest priority item on top. Note however that the priorities have to be captured manually in the title of the issue, i.e. user story, to make it traceable and allow to see priorities without using waffle.
• Note that moving backlog items between columns will automatically assign the corresponding state labels.

User stories

• User stories are implemented as issues in the product backlog repository
• The title of a user story should
  • Begin with US- (for User Story).
  • Describe the content of the user story in as few words as possible with single words concatenated by hyphens.
  • Include the priority of the user story in form of Prio: X concatenated to the title, where X is an integer in the interval [1...1000].
  • Not be changed, as the title may be used to refer to a user story from within a sprint backlog of a Work package. This however does not hold for the priority, which may be changed at any time.
• To visualize responsibilities a user story should be labeled with appropriate owner label Owner WP1,...,Owner WP7 and one or more stakeholder labels Stakeholder WP1,...,Stakeholder WP7. Moreover, the corresponding issue should be assigned to a member of the work package owning the user story.

User stories in progress / handling of tasks on WP level

• For user stories that are currently in progress a break down into tasks should be done in the repository respectively issue tracker of the work package owning the user story.
• An issue representing a task should be set up as follows:
  • Labels representing the name of the corresponding user story of the product backlog should be created and assigned to the issue.
  • Within the issue, the corresponding user story of the product backlog should be referenced using hash tags for the sake of traceability and easy navigation.

Scrum of scrum meetings

• We will have a session for backlog grooming every week on Friday from 9h45 to 10h00 (we might use the WP6 telco slot from 10h00 to 10h15 if the WP6 telco is canceled).
• Mandatory participants for this meeting are the work package leaders (or their deputies).
• The meeting will be announced via the projects google calendar.
• For the initial backlog grooming there will be a dedicated meeting for each of the work packages.