Skip to content
Bernd Hekele edited this page May 12, 2015 · 4 revisions

Status: for review (12.05.2015)

This wiki page describes the implementation of the scrum process for the WP3 teams in the openETCS project. This process is part of the openETCS Scrum of Scrum.

This description is subject of ongoing work as the process may be changed or refined to best fit the needs of the project.

Product backlog of the Modeling Team (WP3)

  • The product backlog is implemented via the issue tracker.
  • The product backlog consists of
    • Use Cases, marked with the label "US-Operational Scenarios on Utrecht Amsterdam".
    • Each Use Cases has an unique User Story label identifing this Use Case in the backlog.
    • (Sub-) User Stories identified as necessary for the implementation of a Use Cases are marked with the user story label,
    • The actual work at the user stories is broken down in smaller technical tasks. These tasks are organised in the sprint backlog. Use the label sprint backlog for defining a task.
    • Remark: We will use specific sprint labels when we better start to organise the work in individual sprints.
  • The sprint backlog consists of prioritized tasks. 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 task respectively issue. Example: US-SpeedMonitoring: Dynamic ASave Calculation 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.
  • When setting a user story to "done" a comment is mandatory for documenting the result.
  • 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. Issue tracker screenshot

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. waffle screenshot

User stories

  • User stories are implemented as issues in the modeling 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],
    • and 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.
    • 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.
  • 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. screenshot user story

Scrum meetings

  • We will have a session for backlog grooming as well as a scum of the modeling team every week on Tuesday from 9h30 to 11h00
  • All active partners of the modeling team are welcome to participate in this meeting.