Agile - sharing experience

The idea with the blog is to share experience about Agile in practice, I have been facilitating CoP (Community of Practice) with Scrum Masters, Product Owners, Team members etc. since 2010 with the purpose of sharing learnings from team to team...

“Learn from the mistakes of others-you can never live long enough to make them all yourself.” quote from John Luther

4+4 planning

Agile in practicePosted by Rune Hvalsøe Mon, February 25, 2013 22:04:38
I will here try to give a short version of how we do 4+4 planning at Sony.

Short overview:

  • 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

The workshop:

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.

Identifying Risks

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

Risk handling

At the end of the workshop, we go through all the risks and try to "solve" them according the the description below....

Risks categorized:

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

  • Comments(0)//