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 help us improve our service offering.
- Transparency: Maintain clear visibility into our processes, decisions, and progress.
Team Roles
- Team Members: Comprising a mix of developers, data and platform 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.
Communication and Delivery
- Daily Stand-ups: A quick get-together to share progress updates.
- Ceremonies: How we make sure our team stays aligned as we work to deliver during Agile Sprints.
Ceremonies
Schedule
This team uses Fortnightly 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:45 - 11:00 |
Show & Tell | Fortnightly | Monday | 15:00 - 15:30 |
Roadmap Monthly Review | Fortnightly | Monday | 15:30 - 16:15 |
Refinement 1 | Fortnightly | Monday | 13:00 - 14:00 |
Refinement 2 | Fortnightly | Thursday | 12:00 - 12:45 |
Sprint Retrospective | Fortnightly | Thursday | 11:00 - 12:00 |
Sprint Planning | Fortnightly | Thursday | 13:00 - 14:00 |
Stand Up
Our stand-ups run daily at 10:45 and last for fifteen minutes. We use Google Meet 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 is run by either the PM, DM, or whoever wants to run it.
Ad-hoc discussions may spin out from stand-up. These should take place after the meeting ends if time allows, or should be arranged for the next available time.
Show and Tell
- Near the beginning of each sprint we have a thirty-minute show and tell showcase that provides an opportunity to share our progress from the previous sprint with the wider organisation.
- In this session we show new features developed for the catalogue, outputs of user research and service design, technical decisions and challenges, among other things.
- Once the content for the session has been agreed, publicise it in the #data-platform-services, #ask-data-catalogue and #platform-architecture Slack channels.
- This session should be recorded so that it can be shared with stakeholders.
Audience
The team, stakeholders, and anyone interested in the catalogue
Roadmap Review
- The roadmap review is a monthly session where the team, stakeholders and users reflect on and amend the product roadmap (hosted on Miro).
- This is an opportunity for stakeholders to share business context which may affect the order in which we do things.
Audience
All of the Data Improvement Programme and any wider audience
Refinement
Purpose:
We use refinement to align the team’s understanding and agree on the units of work for upcoming sprints. It’s where we ensure everyone has an understanding of the backlog items before they are added to a sprint.
Preparation:
Here’s what can be prepared prior to engaging in a refinement session:
- Backlog overview:
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 item review: 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 the team establish sequencing of the tickets during refinement. - Prepare to communicate!: Be prepared to articulate why you think a ticket should be done, how big you think it is, 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:
- Selection: Before refinement, the PM picks out the stories for the team to discuss.
- Discussion: Dive into the details of each story, hash out the acceptance criteria, and call out any dependencies or risks.
- Estimation: Estimate based on effort and risk using a planning-poker scoring system, allowing the team to have a clear sense of the size and scope of each ticket.
- Decompose: Chop up any stories that are too big to handle in a sprint into smaller bits.
- Define ‘Done’: Ensure each story has a clear Definition of Done (DoD) to know exactly when it is crossed the finish line.
Output:
- Refined backlog: Stories that are fleshed out, estimated, and ready for the PM to prioritize
- Scored stories: Each story gets a score so we can try to estimate how many stories we should take on based on our prior rate of work.
- Approachable tickets: All tickets that go through refinement should have all the info required for any member of the team to pick up.
Audience
Data Catalogue Team
Sprint Retrospective
At the end of the sprint, we:
- 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
Data Catalogue 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
Data Catalogue Team
GitHub Practices
Detailed in the Contributing docs.
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