I will here try to give a short version of how we do 4+4 planning at Sony.
- 4+4 planning is a 1-2 days workshop for all teams, PO and SM.
- 4+4 planning should be done every 8 weeks.
- It is a great tool to give the project an overview of what will be implemented within the coming 8+8 weeks.
- It gives the teams an overview of coming work and allow them to deal with dependencies and risks before they become a problem.
- It is a fantastic way to get the teams commitment to the coming work (8 weeks).
- Pictures and comments at last slide from workshop
We started to work according to Agile principles in the beginning of 2011
Team usually never had more than max. 2 weeks view of what was in the pipeline
Dependencies to other teams was a challenge
PO not available for some time was causing problems for the teams
Spikes was hard to plan for
Commitment from PO/manager caused problem for the delivery
Synergy effect through executing related stories was not possible
Let the team know the content of the backlog
Let the team commit to the scope delivery
Allow the teams to identify and address dependencies before they become a problem
Allow the teams to create spike investigation before implementing a user story
Scale Agile planning to meet our needs
Create a huge common backlog for the section
1 day workshop where the teams
* Plan 4 sprints ahead with right level of details to be able to commit
* Plan 4 additional sprints at draft level to know what is coming next
* Identify dependencies to other teams and address them immediately
* Identify risk and mitigate them
SM facilitate the workshop (I facilitated the first workshop)
The teams and PO created several stories before the workshop to ensure that we had enough work to plan for.
We expect that the PO have created the stories before our next 4+4 planning workshop, could involve part of the teams, but less intensive than this time.
4+4 sprint planning:
Purpose: The best planning for the next 4+4 sprints can be achieved when the whole team is doing the planning together. A common commitment to the plan from the whole team is a precondition for success.
When: 4+4 Sprint planning is done in the last week – i.e. every 8th week.
Outcome from each team:
One sheet: Statement of 4+4 sprint objectives
One sheet: Dependencies
One sheet: impediments and risk
Two sheets: Planned experiences for 4+4 sprints
The outcome could look like this:
A closer look at the sprint sheet looks like this:
Each sprint sheet has the teams velocity and how much they load the current sprint, each story have the story point - the team does not load the sprint with more than it believe is possible to achieve.
Building Team’s Detailed Plan:
Estimate velocity for all sprints
* Use current velocity, if known, or ideal developer days if not (8 IDD per team member per sprint)
* Factor in team size, team changes, holidays, vacations
Identify backlog items
* Identify all stories to meet vision/objectives:
* * Experiences, Enablers, other objectives
Estimate stories in (modified) Fibonacci points (0,1,2,3,5,8,13,20,40)
Continuously - Identify and discuss interdependencies
Building Team’s Detailed Plan
Load stories on your sprints until you run out of capacity
Split any stories bigger than 8
Identify any hard dates
State, negotiate, gain agreement on sprint objectives for your team
Identify Dependencies and solve them
Identify impediments and risks and try to solve them or propose solutions/mitigation
Prepare to present your plan
Last: Have your sprint objectives ranked by business value – done by PO
Include maintenance allocation in your schedule
Factor in demo, integration meeting etc
Holidays, training events affect velocity etc.
Dependencies (like advanced widgets, other teams review of our code, Governance board etc).
* Teams DoD for high quality
* Story DoD for right implementation
* Testing – manual, automatic, documentation, …
Architecture – discussions, agreements etc.
Spikes – do we need to investigate something, prove of concept…
Refactoring – Touching code that we need to refactor?
Agree to objectives, rank by business value PO will rank during planning sessions
This has a clear advantage - the PO re-think the value for each story and the team get a good idea of how important the stories are - in case they need to change something in the sprint and the PO is not available. Values should be 1 to 10, the higher the more value to the customer.
Identify those issues that may affect your ability to meet your objectives
Identify potential items first
Address as many as you can during planning
Leave the remainder on your -
risk sheet for broader discussions
At the end of the workshop, we go through all the risks and try to "solve" them according the the description below....
Resolved – has been addressed; no longer a concern
Owned – someone has taken responsibility
Mitigated – team has plan to adjust as necessary
Accepted – nothing more can be done. If risk occurs, release may be compromised