Skip to content

Strategic Development of Coscine

The Coscine development team follows the principles and practices of Scrum to work effectively on maintaining and further developing Coscine. The team consists of various roles, such as the Product Owner, who is responsible for prioritising the product backlog, the Scrum Master, who supports the process and removes obstacles, and the developers, who implement the tickets (known as issues). As with any Scrum team, sprints are planned, daily stand-ups are held, and regular reviews and retrospectives are conducted to ensure continuous improvement. The issues to be worked on during the two-week sprints are selected by the Product Owner. A significant proportion of the issues form part of larger planned strategic developments, known as ‘epics’. Requests for improvements are collected by the service management team, for example in the form of service requests via email or during the monthly consultation hours for 1st-level support. In addition, requests for improvements can also be incorporated into the process directly by the Scrum team or the service management team.

Figure 1 shows the process of Coscine's strategic development in simplified form.

Description of the Coscine process: Service requests are collected, evaluated and developed and improved by the Scrum team in sprints.

Figure 1 - Development of Coscine

Epics

To manage new strategic Coscine requirements for further development, we use Epics. In the Scrum domain, Epics are large, overarching user requirements or functionalities that can be divided into smaller, manageable parts (user stories/issues). They often represent a significant function or an important goal and may take several sprints to be fully implemented. To ensure a good overview and FAIR development for our stakeholders, we handle these Epics in a predefined and transparent manner, drawing on elements of the Scaled Agile Framework (SAFe). For project management of strategic development, we use the Epic section in our Coscine GitLab.

Epic Lifecycle

There are six official phases that an Epic goes through. These can be viewed on the Coscine SAFe EPIC Board. Each Epic is tagged with a GitLab label indicating its current stage in the lifecycle. A predefined Epic Template must be completed for each Epic. Use of the template is mandatory and ensures consistent quality in terms of the depth of information. The status of the Epic is indicated at the start of the template. Depending on the phase, this is done by the Epic initiator, the Epic owner or the SAFe coordinator. A description of the individual roles is provided below.

Who? What? How?
Epic Initiator Creates an Epic Use the Epic Template and fill in the points from Description to Non-functional Requirements
Who? What? How?
Epic-Initiator Informs the SAFE coordinator of the completion of the review Epic status set to Ready for Review and labelled EPIC:Ready for Review
SAFE Coordinator Invitation to the Steering Board Meeting by email to all participants
Epic Initiator Presents the Epic at the Steering Board meeting Max. 5 minutes, focus on the ‘elevator pitch’, no slides required
Steering Board members Voting and decision-making on the EPIC - Epic is moved to the _Analysis Backlog_ (votes greater than or equal than 3, see votes)
- Epic needs to be revised --> remains in review; the EPIC:Ready for Review label is removed
- Epic is moved back to Open (label changed)
Who? What? How?
Steering Board members Evaluates the prioritisation of all epics in the _Analyzing Backlog_ The order is indicated by labels and the position on the board (top = highest priority)
Who? What? How?
Product Owner Assigns the person to the role of ‘Epic Owner’ and moves the next epic to _Analyzing_ as soon as the person in question has sufficient capacity to analyse it The Epic Owner works with the Coscine development team to analyse the Epic and create the relevant issues
Who? What? How?
Product Owner Moves the Epic from _Analyzing_ to _In Progress_ as soon as sufficient development capacity becomes available The Epic and all related topics are being developed and implemented
Who? What? How?
Epic Owner Presents the results at the steering board meeting A brief presentation of the results
SAFE Coordinator Completion of the epic Closing the epic on the board

Relevant roles

Who? What? How?
A member of the Coscine Group Planning, delivering and monitoring services to ensure that customers’ needs are met whilst operating efficiently and cost-effectively Monitoring key performance indicators (KPIs) and liaising with relevant stakeholders
Who? What? How?
A member of the Coscine development team Coordinates Scrum development and the upcoming sprints - Takes over the Epic from the Analyzing Backlog stage and plans the analysis and implementation
- Coordinates the development of Epic-related issues: approx. 50% Epic issues and 50% minor changes and maintenance tasks per sprint
- Informs the SAFe Coordinator and the Steering Board if issues relevant to an Epic need to be postponed due to urgent bugs or maintenance issues
Who? What? How?
A member of the Coscine Group Coordinates the progress of the epics and chairs the Steering Board meeting - Monitoring the SAFe Epic Board
- Updating the status of epics
- Moving epics to the Analysing Backlog
- Adding labels to epics (stage, priority, stakeholders, etc.)
- Planning, preparing and facilitating the Steering Board meeting
- Deciding on the next Epics
- Inviting Epic initiators/owners
- Preparing the votes
- Coordinating the prioritisation
- Keeping an eye on the time (e.g. moving lengthy discussions to separate meetings)
Who? What? How?
Anyone from the RPDM department at the IT Centre of RWTH Aachen University (may be commissioned by an external stakeholder) Initiates a new strategic development - Complete the Epic Template
- Notify the SAFe Coordinator
- Present the idea at the Steering Board Meeting
- Notify the Epic Owner and hand over the Epic for analysis
Who? What? How?
A member of the Coscine development team Analyses the Epic and prepares for its implementation - Notifies the Product Owner upon completion/changes, etc.
- Presents the results at the Steering Board Meeting once the epic has been completed
Who? What? How?
A member of the Coscine development team Helps the team adhere to the Scrum principles - Organises Scrum meetings and facilitates the retrospective
- Encourages open communication and continuous improvement
Who? What? How?
Product Owner, Scrum Master, and developers from the Coscine team A self-organised, interdisciplinary team that works according to the Scrum framework - Planning (2-week sprints)
- Review (presentation of the results of the last sprint to stakeholders)
- Retrospective (reflection on collaboration and processes during the last sprint)
Who? What? How?
Product Owner, Service Manager, Scrum Master, RPDM Group Lead, RPDM Department Head, optional: stakeholders relevant to the epic as guests - Go/no-go decisions on new developments and prioritisation
- Raises questions regarding the strategic objectives of epics
- Focus on alignment with the long-term Coscine strategy
- Voting on Epics and their prioritisation
- Steering Board members can block an Epic by casting a low number of votes (with an explanation of the vote)
- Steering Board members can skip a round in the evaluation (if they lack sufficient expertise)		 Meeting as part of the Steering Board Meeting (an ad hoc meeting to be held no later than two weeks before the next epic is due to go into analysis)

Voting

Each Steering Board member votes on the move from _Review_ to _Analyzing Backlog_ using the ‘fist of five’ method, selecting one of the following numbers:

  1. No way! This will not work. I'm not on board.
  2. I see MAJOR issues that we need to resolve.
  3. I see MINOR issues we need to resolve now.
  4. I see minor issues we can resolve later.
  5. I'm fine with this plan as it is. It's a good plan.
  6. I love this! I will champion it. Best plan ever.

Prioritization

The _Analyzing Backlog_ prioritisation is carried out in an Excel spreadsheet. For backlog prioritisation, Steering Board participants agree on one of the rating figures – 1, 2, 3, 5, 8, 13 or 20 – for each component of the prioritisation formula (user-business value + time criticality + risk reduction).

The RPDM department management may decide to multiply the result by a strategic adjustment (strategic factor of 0.8, 1 or 1.5).