WThe Vaporsith the roots of lean and arguably Agile in the Toyota Production System and Scrum first mentioned in ‘The new new product development game’ there are many Japanese terms used in Agile today.
My concern is the barrier this creates to understanding and the perceived learning ramp for those interested in Agile. In a pragmatic scrum vein I have listed the most popular Japanese terms, a replacement term in English and a brief explanation.
This post is a bit different from usual, dictionaries do not have pictures (once you’re over four at least) so this post looks sparse. I am also not going into the detail or history for each word (however interesting), only how it is relevant today for Scrum. So in alphabetical order lets begin…

  • AndonVisual Indicator – A display, siren or other indicator to communicate information and encourage immediate resolution to problems. A live build and test dashboard on a wall-mounted monitor is a good example.
  • DojoTraining Place – A coding club in which to practice exercises (Kata), often by group practice.
  • GembaWorkface – The place at which value is created, the colocated (ideally) team area in Scrum. Management visit the workplace, look around and ask questions to understand what is being done (gemba walk).
  • Genchi GenbutsyGo and See – Similar to management by walking around the principle is going to the source to find the facts, make decisions and build consensus to achieve the correct goal.
  • HanseiSelf-Reflection – Recognise and reflect upon mistakes in order to not repeat them. To objectively and critically evaluate tasks to find avenues for improvement.
  • JidokaManaged Automation – Automating processes to stop when an abnormal condition occurs allowing a developer to eliminate the root causes of an issue. Automation with a human touch has the steps detect, stop, fix immediate concern and investigate to prevent future issues. Continuous integration is an example of Jidoka enabling quality to be built-in.
  • KaizenContinuous Improvement – Change for the better with small improvements over time accumulating into big results. The retrospective in Scrum is the key point at which to identify improvements and drive the improvement cycle.
  • KanbanSignboard – Scheduling system for work based on pull. In software Kanban is a separate methodology growing in popularity at present.
  • KataExercises – Short practice sessions repeated regularly to perform standard exercises with the aim of broadening understanding and improving thinking. Frequently coding the same pattern allows different methods to be experimented with and the short feedback cycle drives improvement. See the code kata website for example coding exercises.
  • Stages of Learning:
    • ShuCopying – Beginning stage, concentrating on repeating what is being taught.
    • HaReflecting – Expanding upon basic practices by learning the underlying principles and integrating knowledge from other teachers.
    • RiExtending – Adapting and creating knowledge from your own practice and circumstances.
  • The Three Ms of Lean:
    • MudaWaste – Activities not creating value, reducing waste is a key just-in-time method to improve profitability.
    • MuraUnevenness – Unfair demands on process, machines and employees reduces overall productivity.
    • MuriOverburden – Unnecessary stress to process and employees targeted by the Agile manifesto with sustainable development at a constant pace.
  • Niko-nikoHappiness Index – A tool used to track the mood of the team. Often a calendar on which developers draw a smiley on as they leave work to indicate their average mood for the day. Note that this produces useful source data for retrospectives.
  • ObeyaWar Room – A room used by a project to display all project charts and plans, acts as a single location for the team in optimising a project. Visualisation and a shared space improves team interaction.
  • Poka-YokeMistake Proofing – Prevent mistakes from occurring or detect them quickly so that they are fixed immediately during development. Examples in software include designing dangerous features out of a language (automatic garbage collection in Java), reminding users there is no title on an e-mail before sending or highlighting invalid commands within an IDE.
  • The 5S Methodology –
    • SeiriSort – Removal of unnecessary items and removal of obstacles.
    • SeitonSystematic Arrangement – Arrange necessary items to make workflow smooth and easy.
    • SeisoShine – Keep the workplace safe and easy to work within plus use the cleaning process to also maintain required equipment.
    • SeikutsuStandardise – Create processes to reinforce good practice, maintain orderliness and organisation.
    • ShitsukiSustain – Perform training and regular audits to keep the workplace efficient.

That’s it, please send me any other Japanese terms to add to the list along with the English alternative.

Team Pyramid

Colocation, let me just start by saying colocated teams are more successful period. Far-located teams have a success rate of 60%, near-located 72% and colocated 83%. Given the increase in success rates it is surprising that still less than half of Agile teams are colocated.

I am looking in this post at the ideal for most individual teams and why we should all strive for it.

Location, Location, Locationlocation location location

As Phil and Kirstie know location is key, between team members a coach length away may as well be a coach trip away for the reduction in communication caused.

Ideally the scrum team needs to work together in a common space, all within around six meters of each other. By sitting close together you can have a quick discussion without leaving your desk or having to raise your voice.

We Need To Talk…We Need To Talk

The main reason for colocation is to make communication richer, more open and simply quicker. By maximising face-to-face communication we gain quick clarification, resolve issues faster and avoid wasted time waiting for answers to e-mails and messages.

Phone calls, video-conferencing and collaboration applications are all great but do not beat the immediacy of being able to overhear a conversation and instantly spin around your chair, jump in and help. The context and depth of interaction is also reduced when the speaker is not physically present, 60-90 percent of communication is non-verbal (gestures, posture, tone etc.).

Alistair CockburnAlistair Cockburn succinctly states “The speed of the project is the speed at which ideas move between team members”. Another term coined by Alistair Cockburn in his book Crystal Clear: A Human-Powered Methodology for Small Teams is osmotic communication where information flows in the background hearing of team members who pick up and respond to relevant points as required. This selective tuning-in and tuning-out is further explained as selective attention or the cocktail party effect.

What’s The Problem?Trolls Frozen

From cubicles creating barriers, functional groups forcing formal handovers and the lack of trust increasing valueless documentation companies seem to go out of their way to hamstring teams.

Further benefits of colocation include:

  • Cross-functionality: Integrating functional disciples within a single team reduces silo mentality and promotes cross-disciple working. In Agile we seek to encourage generalising specialists and T-shaped people.
  • Removal of travel time: Distributed teams need to travel to shared meetings and potentially find ways of working across time zones. It is quicker to organise and attend meetings when everyone is in the same place.
  • Trust: Closer working relationships develop faster when working alongside colleagues. It is easier to build trust when you can see the actions of others in response to agreed actions or commitments.
  • Improved team behaviors: Tribal behaviors develop team working and reinforce positive collaboration.
  • Co-operation: The opportunities to assist each other increase with colocation and helping each other increases trust and team working by means of a positive feedback loop.

Let’s Talk About The IssuesIssues Title

Hey, this is a pragmatic scrum blog and not everything even in ‘Pure Scrum’ is going to be perfect – sorry to break it to you now.

There are potential problems with colocation, especially initially:

  • Forming teams separates people from their functional groups (HCI, databases, test etc). Effort is required to still share knowledge across multiple teams, this is usually performed by communities of interest (or Guilds at Spotify).
  • Background noise can be distracting. Colocation in scrum leads to a raised level of conversation that the team and those surrounding them need to get used to. Note that pair programming can reduce the acclimatisation time for those involved.
  • Working on multiple projects is still common; colocation can reduce the ability to multi-task. Providing hot-desks within each team area for shared resources can alleviate this issue.

This Is How We Do ItHow do we do it?

First we talk with the stakeholders; I want project management and the full team to buy-in to colocation. We really need their support to move people within offices and ideally prepare the right environment. Gain agreement from HR, product management, finance and whoever else is required to make the changes.

As well as the usual requirements I want to see lots of whiteboard space, paint the walls with whiteboard paint or even better install long magnetic whiteboards. If you are low on wall space use wheeled whiteboards, static roll whiteboards or whatever else you can create to provide information radiators and big spaces in order to design and discuss work.

Work with facilities management to create room for the team. Try for a shared area, close desks, quiet spaces and a meeting room with a projector and tele-conference/video-conference facilities (as required).

When planning desks, aim for programmers to sit together with the testers (assuming they are still different people at this stage) to sit alongside. Sit domain experts and HCI engineers close enough for questions. The PO and PM (most Agile teams still have one) are usually located close enough to be aware of the teams work but far enough away as to not annoy the team with their constant talking on the phone.

Are we restructuring the entire company into teams with their own perfect environment – no, and even if we could this big bang approach is fragile and risky. Start small, show success and then scale incrementally, this takes time. Each team is different as each person is different, this needs to be recognised. Do not force change on people, they will leave.

Environment is easy, what about the team themselves? We are moving from individuals working separately to teams co-operating and collaborating. Work with a coach to focus on soft-skills within the team, encourage interruptions, prioritise helping others and share knowledge and skills.

PragmatismTeam Table

So can we still use a distributed team, yes of course but it will not be as productive as one that is colocated. We will need to utilise webcams, video-conferencing, co-operative tools and a willingness to travel to attempt to compensate.

It is essential to get the team to drive the colocation and work with the local powers to make it happen. Guerilla tactics, weekend desk rearrangements, booking hotel rooms for six months and re-purposing conference rooms were all great methods ten years ago but the worlds moved on. Persuade your management, pull down the cubicles and remove the barriers (physical, structural and mental) to successful teams.

And finally, in the worst possible situation remember Bas Vodde’s remark “change your company, or change your company”…

Thanks for reading and I would love to hear from you if you think of other benefits or issues involved with colocation of an Agile team.

TargetA Sprint Goal provides a focused objective for the team to produce an increment of software. It consists of a short description of a business or technical outcome that the team plans to achieve during the sprint, for example “Implement basic user profile entry (CRUD: create, read, update and delete)”.

Each sprint should be given a unique goal stating why the increment is worthwhile; this acts to align the team whilst planning, during the sprint and at the review.

Benefits of a Sprint Goal

The advantage to having a sprint goal is that it helps with –

  • Prioritisation – A goal supports the ordering of product backlog items when selecting content for a sprint. The Product Owner should select the initial goal for the sprint and then select stories to support that goal. Note that during sprint planning the scrum team may agree to change the sprint goal to reflect the work finally selected. Within the sprint the goal also becomes vital for the team when they are deciding ordering for tasks.
  • Focus – As well as providing a basis for the sprint planning session the goal provides a reason and shared objective for the increment to guide the team and enable commitment. The target is then for the team to accomplish the sprint goal and not just to complete the list of selected stories.
  • Feedback – Having a goal makes it easier to identify relevant users to review the increment and to receive quicker focused feedback. Analysing the feedback against a single goal is also easier than multiple disparate comments raised against several different stories.
  • Communication – Speaking to stakeholders and other agents outside of the team is easier when discussing what a sprint is for and helping them to decide if they should be attending the sprint review.

Creating a Sprint Goal

smartThe product owner and development team agree the goal collaboratively in part one of sprint planning and like all targets it must be SMART:

  • Specific – The goal needsto be clear and unambiguousrather than generic. For a specific goal the team must agree on what is important, why is it needed, whois required, where it’s going to happen and which elementsare required, thiscan be summarised as the five ‘W’ questions:
    • What needs to be accomplished?
    • Why is it required?
    • Who is involved?
    • Where it is to be done?
    • Which product backlog items are needed?
  • Measurable – The goal needs progress to be quantifiable, whether this is by seeing progress by the number of stories completed or by associated acceptance tests.
  • Attainable – It must be realistic for the team to be able to accomplish the goal within the sprint considering all other factors. A stretch goal by a high-performing team is fine if they decide to write it but, as always, it is the team that decides to accept the goal or not.
  • Relevant – The goal must address a challenge upon the project and move the team closer to the release or overall vision. Early sprints often focus on the reduction of risks and uncertainty (learning), later sprints generally focus on delivering customer features (delivery).
  • Time-bound – The goal must be achievable within this sprint.


The goal should be displayed prominently on the task board during the sprint so that the team can reflect on it at each daily scrum.

During the daily scrum the team answer three questions that reinforce the goal and work to re-align the team each day:

  • What did I do yesterday that helped the Development Team meet the Sprint Goal?
  • What will I do today to help the Development Team meet the Sprint Goal?
  • Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

Roman Pichler shows an image including the sprint goal displayed on the task board in his excellent post on effective sprint goals:


Failing to Meet the Sprint Goal

If the goal is rendered obsolete then the product owner should cancel the sprint, this is understandably rare. Sprint goals can be missed by teams due to many reasons – insufficient understanding, over-committing, discovery of technical debt, resource reduction etc. Missing a sprint goal is an essential item to be raised during the sprint retrospective to find the underlying reason.

Accomplishing the Sprint Goal

Good work, the sprint goal has been demonstrated in the review and accepted. Another successful sprint chalked up, onto the retrospective and then straight into planning the next sprint.

Meeting the Spring Goal Early

Reality annoyingly does not always reflect estimates so sometimes a team will accomplish the sprint goal early, does this mean an early trip to the pub? Unfortunately not, the Scrum Guide states that the development team must collaborate with the Product Owner upon the scope of the Sprint backlog, this enables additional product backlog items to be pulled into the sprint.


The Sprint Goal is a great device utilised by Scrum Teams to add cohesiveness to each cycle of development. High-performance Scrum teams probably no longer need this uniting target and good luck to them, this blog is called Pragmatic Scrum for a reason so for now I will still be using a Sprint Goal.

Quick question, what sprint length do you use and why?Tape Measure

My guess is that you answered two weeks, I’m right aren’t I – well at least around 60% of the time.

Rally Software’s 2014 survey, based on 89,115 responses, shows the following results for the percentage of Scrum teams that use each sprint length:


The Scrum Guide being the fount of all knowledge gives the following rule – a sprint is a “a time-box of one month or less”. I don’t want to appear hardline but if your sprints are longer than a month you should really consider if you are doing scrum at all.

Fixed Sprint Length?sl3

When a sprint is in progress it’s duration cannot be changed, unless it is cancelled of course. The scrum master, in collaboration with the development team and product owner can elect, prior to a sprint beginning, to alter the duration.

The process is usually that duration is discussed in the sprint review in response to an issue and investigated within the sprint retrospective. When a collective agreement is reached the scrum master can decide whether change the sprint length, or not. The scrum master should strive to reach a consensus with at least the development team, as an adversarial relationship is not going to operate well at that level.

There is advice stating that if teams struggle to achieve all of the work within the sprint then the duration should be halved in order to force the issue and encourage change. This may be worth trying but really only in agreement with the team as it will be difficult.

Do not change the sprint length frequently as velocity becomes meaningless, meetings become difficult to organize and the team will be disrupted. Having said that do not be frightened to alter the sprint length if the project or team requires it.

One exception to this is the popular practice of running the first three sprints at one week for a new team to force the process under pressure to bed in. The first three sprints are usually all over the place in terms of velocity for a forming team so the risk is low. After the three learning sprints the team will generally revert to two weeks for the rest of the project.

Release sprints or hardening sprints are controversial but used by some teams still transitioning to Scrum. They are usually kept to the length of a normal sprint so as to avoid breaking the team rythm. Using a longer sprint reduces the need for these ‘false’ sprints.

Selecting a Sprint Lengthsl4

There is a lot of advice out there for selecting the duration for sprints based on risk, return on investment, feedback cycles, market dynamics but really my advice is just to pick two weeks and see how it goes.

The Goldilocks principle specifies that things should fall within defined margins, away from extremes. For most projects four weeks is too long and one week is too short so two weeks is probably just right.

Good overall advice for sprint length is “as short as you can, but no shorter”. If you cannot achieve a completed story with end-user value in a sprint to the product owner’s satisfaction then consider increasing sprint lengths, but only after trying everything else.

Converting teams from traditional methodologies to Agile is a journey, if as a group they feel that they need to start with a four-week cadence due to cultural, environmental or projects issues then accept it – for now.

You will see advice saying to avoid three week sprints, don’t listen – quoting natural cycles and the difficulty of synchronizing three weekly events is all rubbish. Three weeks is the second most popular choice for sprints, in my mind it’s not as good as two weeks (or even one) but at least it is better than four.

Shorter sprints, one week or less are great if you need to innovate faster than the competition and pivot quickly whilst seeking value. Lean start-up, fail-fast, excitement and energy are all heightened in shortened sprints, unfortunately so is the risk of burnout, incomplete work, lower quality and a short-term viewpoint. Day sprints would be great as well but only for the appropriate development.

With multiple teams working on a common product backlog it is important to synchronise sprint lengths. By this I mean that they need to align, not that they need to be the same. For example a HMI team may be running two-week sprints whilst the hardware team is on four-week sprints, they will still align once a month. In this case I would advise against three-week sprints, as they are a pig to align…

As always we have a complication, some teams use sprint zero as a preliminary increment in order to form the team, set up the development environment and perform enough architecture and design so that the project can begin. Sprint zero is limited to a maximum of three times the normal sprint length; with an average two-week cadence this gives a maximum length of six weeks. The Scaled Agile Framework defines an “Architecture Runway” for effectively the same purpose.

Long Sprintssl5

Teams with durations over two weeks often give some of the following justifications:

  • It is too difficult to break stories up for shorter sprints and still produce features with customer value. Longer sprints produce a viable product (false argument: improve story refinement)
  • It may be easier to have less frequent sprint planning meetings for larger teams (false argument: do better refinement to reduce and focus Sprint Planning)
  • It could be considered that shorter sprints do not suit long projects and month sprints may be better (false argument: reducing feedback cycles is always better)
  • There is less innovation in shorter sprints as teams will pick a risk adverse method in order to solve an issue, this may not be the most innovative or optimal solution (some validity but can generally be resolved by using spikes to prepare riskier stories)
  • Stake holder exhaustion, attending more frequent sprint reviews may not be viable or desirable for customers (some validity: the team would benefit from shorter cycles although the duplication of reviews for less frequently visiting customers is a waste. This is a balance in which a reduced frequency of customer involvement is not ideal but is reality for many projects)
  • Manual regression testing is not possible in short iterations (some validity: transforming legacy projects is difficult when testing is still manual, until this situation is remedied it may be better to run longer sprints)
  • The product owner may not be available to perform the role frequently enough for short sprints (false argument: the team either needs a new product owner or the PO needs to reflect on their responsibilities…)

I would ask these teams to consider experimenting by switching to two-week sprints for the following reasons:

  • It is easier to maintain a bow-wave of six weeks of sprint-ready stories (three times the sprint length) than twelve weeks worth
  • The team will be more agile and able to adapt to market and project conditions as there are less prepared stories
  • It is generally possible for the team to keep in mind all of the stories within the sprint and co-ordinate better
  • Scrum events (excepting the Daily Scrum) are halved in duration for two week sprints over four week sprints, this increases team focus and energy within meetings
  • Engineers still remember what they did at the start of the sprint, retrospectives can get slow when trying to remember four weeks back
  • Transparency is improved by shorter sprints allowing stakeholders to review and feedback on completed work more often
  • Feedback cycles are shorter for stakeholder feedback and also for sprint retrospectives. These frequent checkpoints make project progress easier to assess and future work simpler to plan
  • Longer durations allow teams to regress to waterfall within each sprint (ScrumFall)
  • Fail fast, if you are going to fail an entire sprint it is better if it is shorter at least
  • Shorter sprints increase motivation, four weeks sprint start casual, have lulls in the second and third weeks prior to rushed work in the fourth week to finish. This is similar to student cramming behaviour…
  • Shorter sprints tend to get disrupted less by stakeholder interrupts who can often await the end of a fortnight but will rarely wait for a whole month
  • Shorter durations encourage teams to work together in order to achieve the forecast work within the sprint, this also encourages teams members to work outside of their comfort areas
  • There is a good reason around sixty percent of teams choose two weeks, this is backed up by being the popular choice of many Agile trainers and coaches


Scrum provides great opportunities to inspect and adapt so collaborate to select an initial sprint length and following a bedding-in period of at least two sprints discuss and decide how to move forward.

Do favour shorter sprint durations over longer ones due to the improved feedback cycle but in summary, do what is right for your product and allow the team to decide.

Thanks for reading this far and apologies for the long posts, all aspects of Scrum are deceptively simple in theory but have so much depth in practice. The next post will be on the Sprint Goal, should be nice and short – or not. Please sign up if you would like to receive an e-mail whenever new posts are added.