3 week sprints
The idea:
1 Week for the team to have all of their sprint ceremonies, one to ones , story grooming and whiteboard solutionising sessions for the one week in preparation for the two weeks of development. Which should be uninterrupted and meeting free apart from the daily standup.
The rules:
- The development should be uninterrupted unless of production issues.
- Sprint work no tickets, bugs or spikes are worked on
- Requires everyone in the team to be committed
The Problem:
We expect teams to focus on a number of different activities during a sprint, any context switching between these activities is inefficient e.g.
- Coding (development, tech debt and bug fixing)
- Peer review of coding
- Peer review of user story (have we met DOD)
- User story refinement (provide DOR)
- Sprint planning
- Discovery (for backlog and industry best practice)
- 1 to 1s
- Personal development
- The team felt they could be more effective (less frustrated) if we could reduce this,
Solution:
Reviewed problem with team and identified the main activities that impacted coding work for an enabling team
- Backlog refinement
- Sprint planning
- Technology upskilling for team (white boards, lean coffee, brown bags)
- Architectural updates (whiteboard mob sessions)
- Sprint review
- Sprint demo
- Sprint retro
- Personal development
- 1 to 1s
We then discussed different approaches to resolve;
-
Maintain 2 week sprint but specify certain days of the week or certain times of the day which would be focused on non-coding activities – rejected as team felt it would be difficult to effectively spilt a 2 week sprint and achieve all work required in review and planning
-
Create a non-coding week (5 working days) , team felt this gave us a great window of opportunity to review and plan, refining user stories, technical and architectural upskilling – 5 days guarantees all the required elements can be completed (not felt to be the case in 2 weeks sprint)
2 & 1 Structure
General Rules for sprint approach:
- Spikes or research pieces do not spill over into the 2 week development time
- Development stories, bugs or tech debt do not spill over into the planning & investigation week.
- Only business critical priorities can disrupt this 2 & 1 week with justification i.e fixing a live P1 issues.
1 Week (Planning & Investigation)
Goal is to go through all spikes and start of sprint activities, give thinking time to flesh out stories for the next or future sprints and give the team some thinking time to explore new opportunities or define a technical solutions for the upcoming sprints.
Wednesday (Day 1)
- Sprint review
- Sprint demo
- Retrospective
Thursday (Day 2)
- Refinement session (first time the team see the tickets for the next sprint) flash out acceptance criteria and plan whiteboards sessions
- First whiteboard session
- Learning time (investigation or discovery around spikes, tech debt or personal development - ideally all ticketed for transparency)
- Any required stakeholder meetings
Friday (Day 3)
- Refinement session
- Whiteboard session
- Learning time (investigation or discovery around spikes, tech debt or personal development - ideally all ticketed for transparency)
- Any required stakeholder meetings
Monday (Day 4)
- Refinement session
- Whiteboard session
- Learning time (investigation or discovery around spikes, tech debt or personal development - ideally - all ticketed for transparency)
- Any required stakeholder meetings
Tuesday (Day 5)
- Sprint planning
- Define sprint goal
- Final story pointing
- Identify the stakeholders for the sprint demos
2 Weeks (Pure Development)
Goal is to complete the work committed to in the sprint with minimal disruption and content switching, so that the team can confidently demo the enablers from the sprint to relevant business and technical stakeholders at the end of the sprint.
- Non-urgent stakeholder meetings will be pushed back to the 1 week to limit context switching in this time
- Pure development time for the team to build solutions
- Proof of concepts will be part of the 2 week development time
- BAU pull request reviews
- Frontendstarter_kit channel support (24hr SLA to provide a response)