Core Platform Team/PET Work Processes/PET Work Process

Purpose
The Core Platform Team(CPT) and its sub teams is working to adopt processes that are optimised to improve the consistency and sustainability of our work load, predictability of our delivery, facilitate integration and collaboration with teams across the org, and to create space and support for our Engineers to focus on their work with the least possible administrative overhead.

Our processes should be clear, concise and straightforward for others to plug into, whether they are joining as new members or working collaboratively with us.

Structure
Our team's work is decomposed from FY Roadmap -> Projects -> Tasks



We've begun structuring our work loads in 2-week bounded cycles that consist of


 * Pre-sprint Planning


 * Kick-off
 * Mid-sprint Check-in
 * Retrospective

The work is supported further by special meetings as well as tools and methodologies.

Meetings
The CPT is trying to use a time boxed sprint structure to identify and complete work that is driven by the requirements of its core projects. The current time bounding is 2 weeks.

Pre-sprint
Prior to the beginning of a sprint a subteams Tech Lead, Product Manager and Engineering Manager meet to identify, define and select the individual tasks that will comprise the sprint. The selected tasks should be
 * Chosen so that they fit into the space provided by the sprint in terms of complexity.
 * Prioritised clearly
 * Estimated in terms of difficulty

Kick-off
During this meeting the tasks which will comprise the next sprint are presented to the team for evaluation and discussion. The team can discuss the priorities and estimations of tasks and where necessary the scope of the sprint can be adjusted.

Check-in
The Check-in meeting is held in the regular teams meeting slot the week immediately following the Kick-off meeting. It is the mid point of the sprint where
 * Sync on progress in terms of the sprint goals
 * The team discusses any urgent technical issues, resources, blockers or tensions
 * Communicate any changes to scope that needs to be made

Based on the Check-in meeting, the Product Manager, Program Manager, Engineering Manager and Tech Lead can reprioritise or (re)(de)scope tasks.

Retro
The goal of our processes is that they be adaptable over team to reflect the evolving nature of our teams, our projects and the needs of the both. The process should adapt and team members should have both agency and ownership.

At the end of a sprint we perform a 30 minute facilitated retrospective meeting where all participants in a sprint collaboratively identify what worked well, what needs improvement and what was learned during the sprint. Depending on the number of items raised they are prioritised and discussed.

The output of the meeting is a set of actions to implement in future sprints. These actions can be improvements/changes to the process or highlight behaviours that should continue and be further supported.

The agenda for a retro is as follows:


 * 1) Generate Liked (2 mins)
 * 2) Generate Lacked (2 mins)
 * 3) Generate Learned (2 mins)
 * 4) Vote on priorities for discussion (4 mins)
 * 5) Generate Actions/Improvements/Continue discussion (20 mins)

Triage of Tasks
On a weekly basis the Program Manager, Engineering Managers, Product Managers and Tech Leads meet for 1 hour to groom our 3 main workboards:
 * #core-platform-team
 * #cpt-kanban
 * #cpt-backlog

The goal of this process is to ensure that tasks are monitored and progress through our work pipeline, prioritise outstanding work and to unblock any stuck tasks.

In general the team works through the boards as follows:

Prioritisation
Tasks should have a clear priority to ensure that the work that has the greatest impact on progressing our goals or meeting deliverables to done first.

Priority is determined collaboratively but is owned and directed primarily by the Product Manager.

Estimation
Tasks are estimated on an integer points basis. The goal is divide tasks into clear buckets that reflect their complexity.

Complexity is a combination of difficulty in completing the task, dependencies on other teams or work, amount of work required and technical complexity.

Tasks that have very high scores in complexity should be considered for conversion to epics and decomposed into appropriate subtasks of more manageable size.

We currently experimenting with using sizes of small, medium, large. Though this will likely need to be refined.

Milestones
In future projects the CPT will ensure that all projects are planned with milestone with a focus on deliverables: things we can ship, deploy, and/or demo.

We will strive to answer questions like:
 * What is the next milestone for this project and when?
 * What will a sub-team ship this month?
 * What can we demo about this project?