Ways of Working

What are our Core Values?

Collaboration: Foster a culture of open communication and collective problem-solving.
Quality: Uphold high standards in our work, ensuring reliability and efficiency.
Innovation: Embrace new ideas and technologies that propel us and our platforms forward.
Transparency: Maintain clear visibility into our processes, decisions, and progress.

Team Roles

Team Members: Comprising a mix of developers, data, platform and software engineers, responsible for the delivery of tasks and active participation in all Agile ceremonies.
Product Manager (PM): Oversees the product backlog, ensuring it aligns with stakeholder needs and business objectives.
Delivery Manager (DM): Facilitates the Agile process, removing blockers and ensuring timelines are met.
Technical Architect (TA): Works with delivery teams to decide on technical requirements and improvements which align with wider practices.

Communication and Delivery

Daily Stand-ups: A quick sync to share updates, plans, and blockers.
Ceremonies: How we make sure our team stays aligned as we work to deliver during Agile Sprints.

Ceremonies

Schedule

This team uses 3 week Sprints This is our timeframe for planning, executing, and reviewing work.

The team has the following ceremonies:

Ceremony	Occurence	Day	Time
Stand Up	Daily	Monday - Friday	10:00 - 10:15
Refinement	Weekly	Tuesday	11:00 - 12:00
Sprint Planning	Every third week	Thursday	10:00 - 11:00
Sprint Review	Every third week	Thursday	10:00 - 11:00
Sprint Retrospective	Every third week	Wednesday	10:00 - 11:00
Show & Tell	Every third week	Wednesday	15:00 - 15:30

Stand Up

Our stand-ups run daily at 10:00 and last for fifteen minutes. We use Slack Huddles and follow one of two formats:

Walk The Board

Starting with the “Done” column we discuss any active issues on our GitHub Project Board.

Yesterday, Today, Blocked

A round robin of each team member discussing their issues and any blockers.

Standup will be run by the Delivery Manager.

Backlog Management

Purpose:

Backlog Management is where we ensure our backlog is up to date and ready for refinement. It’s where we:

Prioritise stories - Give a clear picture of what the team is working on, and will be working on next
Remove stale stories - Keep the team focused on only relevant work
Remove irrelevant stories - Prevent the team’s focus from being split with work that’s not required

Process:

TBD in consultation with PM/DM.

Output:

A well prioritised backlog
A backlog that is ready for refinement and free of stale/irrelevant stories

Audience

Product Manager
Delivery Manager
Leadership Team

Purpose:

Refinement’s our time for the team to get an understanding and agreement of what we are working on in upcoming sprints. It’s where we ensure everyone has an understanding of the backlog items before they are added to a sprint.

Prerequisites:

Prior to engaging in a refinement session, here’s what can be prepared:

Backlog Familiarisation: Review the backlog to get a sense of what’s coming up, and what’s already been done. Read the tickets likely to come up for discussion, so you know what questions you want to ask
Backlog Items: Ensure any tickets are well fleshed out and ready for discussion. This should include a detailed description of the story, as well as acceptance criteria
Understand Dependencies: If your tickets rely on other work already being done, know which tickets are required and list them in the body of the issue. This helps us understand correct sequencing of tickets during refinement
Prepare to Communicate!: Be prepared to articulate why you think a ticket should be done, how big you think it is, and be receptive to teammates, and collaborate to achieve a shared understanding of the tasks at hand. Be open to suggestions on how your ticket could be improved for someone picking it up

Process:

Preparation: Before refinement, the Product Owner picks out the stories that need our attention
Discussion: Dive into the details of each story, hashing out the acceptance criteria, and spotting any dependencies or risks
Estimation: Estimate based on effort and risk using a poker-scoring system, allowing the team to have a clear sense of the size and scope of each ticket
Decomposition: Chop up any stories that are too big to handle in a sprint into smaller bits
Definition of Done (DoD): Ensure each story has a clear DoD to know exactly when it is crossed the finish line

Output:

Refined Backlog: Stories that are fleshed out, estimated, and ready for the Product Owner to prioritize
Scored Stories: Each story gets a score for a straightforward understanding of what we’re up against
Tickets Approachable: All tickets that go through refinement should have all the info required for any member of the team to pick up

Analytical Platform Team

Sprint Planning

Purpose:

Sprint Planning is where we figure out what work we want to commit to for the next sprint. It’s where we:

Discuss and align on the goals for the upcoming sprint
Select stories from the refined backlog, ensuring a shared understanding of scope and objectives
Define the sprint goal
Define the sprint backlog

Process:

Discussion: Discuss the stories in the refined backlog, ensuring a shared understanding of scope and objectives, including any work carried from last sprint
Highlighting: Highlight stories and spikes that are significant to delivery of the sprint goal
Capacity Estimation: Estimate the capacity of the team for the sprint, and assess whether the tickets brought in match that
Sprint Backlog: Select the stories that will be brought into the sprint, and assign them to team members where appropriate

Output:

Ensure everyone has stories that they feel they can work on
Ensure everyone has a shared understanding of the tasks to deliver this sprint

Audience

Analytical Platform Team

Sprint Review

Usually encorporated with Sprint Planning
A chance to discuss completed work to share knowledge within the team

Audience

Analytical Platform Team

Sprint Retrospective

We have our retros at the end of each sprint currently on Wednesdays. The retro format may be different for each sprint

Reflect on the sprint’s process, celebrating successes and identifying opportunities for improvement
Review the process, not the stories
Define how we could improve
Share kudos and feedback

Audience

Analytical Platform Team

Show and Tell

At the end of each sprint we have a thirty-minute show and tell showcase to share with our colleagues and the wider organisation our achievements during the sprint
The showcase normally consists of an introduction summing up the sprint and if we met our sprint goal followed by demonstration and then what’s next in the road map

Audience

All of Data Platform and wider audience

GitHub Practices

We utilise GitHub for managing code, documentation, and support, with GitHub Projects for tracking work and GitHub pull requests for reviewing and merging code
When working in our repos, please adhere to GitHub housekeeping guidelines when creating pull requests, ensuring clear titles and descriptions, linking to issues when applicable, and requesting reviews upon readiness

GitHub Housekeeping

When creating a pull request, ensure you have a clear title and description
If applicable, link your pull request to an issue with the special keywords such as closes, fixes or resolves GitHub documentation for linking pull requests to issues
If your pull request is not ready for review, convert it to a draft
When your pull request is ready for review, remove the draft status and ensure all checks are passing
When all checks are passing, use the /pull command in #analytical-platform to request a review

Support

Each member of the team is included in the support rota
Support cover is for one day (09:00-17:00) as allocated by the rota
PagerDuty is used to manager our support rota
If you are unable to cover support please arrange cover and create an override within PagerDuty

Support Duties

Monitoring the Slack support channel
Actioning raised issues or seek support from team to do so
Run that days standup
Respond to PagerDuty alerts, support issues on GitHub, and review pull requests

Process

In order to keep our users updated and the backlog tidy, when on support follow these best practices:

When a new issue is raised in GitHub remove the triage label, assign the issue to yourself, and unassign the robot account
Add the investigating label to indicate to the user that you are looking into the issue
Add the awaiting-response label if you reply to the user to ask a question or request further information
Add any further relevant labels related to the issue, as having these correct helps with our monitoring and understand of support
Close the issue in GitHub when it is resolved, documenting the steps you took to resolve it, and any further relevant information e.g. link to team discussions in slack. This will help future support leads find common solutions and related issues

Working hours

A member of the support team will be available online from 9:00 and until 17:00 (Monday-Friday). Any requests outside of these hours will be at the first available opportunity based on team capacity.

Delivery

Development: Implement, test, and document stories, adhering to our Definition of Done
Integration: Collaborate with the other delivery team to ensure smooth integration and alignment on shared goals
Deployment: Follow our deployment checklist for a smooth transition from development to production

Continuous Improvement

Actively seek feedback from all team members and stakeholders
Review and update our Ways of Working as necessary to reflect our evolving process and learnings
Effective use of all our ceremonies especially retros
We will support each other and give constructive feedback
We avoid back to back meetings which can be very draining
We take note of issues in retro and action them promptly

This page was last reviewed on 18 July 2024. It needs to be reviewed again on 18 October 2024 by the page owner #analytical-platform-notifications .