Doing localization each Sprint

Question

We need to support 5 languages for our product. This means that in order to have a potentially shippable product we need to translate all text new to the Sprint to all these languages. It doesn't make sense to me because the text might change after a few Sprints during which the users will use the application and give feedback. So paying the translating company for translating text that will most likely change doesn't seem to be a wise decision. So what do you do with localization in Scrum?

Answer 1

Put simply this, like many process questions, comes down to a cost-benefit decision.

Quite a few of the practices described in the agile processes are about reducing the time spent in the "last mile" - this is an example of one of them.

Unlike practices with other aims (quality, correctness, etc), the practices aimed at ensuring you can release the product at any time have a net cost associated with them.

Ensuring that the product you are developing remains ready to release at all times has a cost that is not directly turned into benefit in the same way as ensuring it is at production quality.

I split those two aspects up as they have important differences. For example:

Ensuring a product is well tested and bug free at all times has a cost, but the benefit is reduced time to fix bugs as they are found, produce new features, and decreased chance of large scale rework after bugs are found to be fundamental. Almost all the time the tangible benefit will be greater than the tangible cost.

Ensuring a product is quick and simple to release has a cost but will will save you when you come to release, and the benefit is multiplied when you release frequently. The more often you release the more likely that the cost will be realised in savings. Again, the tangible benefit will generally be greater than the cost.

Ensuring a product is properly localised at all time has a cost, but will rarely result in a tangible cost benefit. This is particularly true when a third party is involved as a long standing and ongoing relationship with a third party will generally cost more (in time and cost) than short bursts of piece-work.

The question is, are there other benefits that you gain that makes the cost worthwhile?

In this case the biggest benefit is likely to be the ability to reduce time taken from release candidate to actual release - it comes back to the 'last mile'.

One way to think about it is as stock in a warehouse. Developing software is a way of building up stock - until that stock is on the shelves (the software is released) it does not generate revenue. In some scenarios it even drops in value as it sits on the shelf.

So one question you can ask is "How long can we put up with our stock being on the shelf without generating value?". For internal efficiency based systems this may be weeks, for innovative first-to-market products this might be hours. The shorter the time is, the more "ready for production" you need your software to be at all times.

Another question may be "How likely is it that our customer will decide at an arbitrary point to release the software?". That is, in sprint 3 of 6 they decide that they like the software so much that they want it straight away. If the situation is likely, how long will they be comfortable waiting?

Also, will seeing the software in its entirely localised state throw light onto questions that would otherwise remain unanswered? Does seeing a translated version of the site generally make the customer change direction, or help validate the current direction? Is there therefore value in seeing it earlier in your process?

Do you have other processes in the "last mile" that will hold you up longer? If the only thing you're waiting for in the last 2 weeks are the translations then you will generate a bigger benefit than if would still have to wait 2 weeks for infrastructure to be upgraded, senior stakeholders to sign work off, etc.

Why do you find you need to do re-translations? Is it because the requirements of the text change as the system develops - an inevitable consequence of change in the system. Or is it more that people are unwilling to commit to a body of text early in the process when they probably should be able to. Could continual translation focus their minds on ensuring correctness at all times?

Finally, how much extra will this all cost? Have you looked at the amount of re-translation will be required? What is the incremental cost of doing the translation piecemeal? If this is a cost-benefit decision, you need not only to clarify the benefits, but work out the tangible cost.

So, my advice would be:

• Work out the benefits in your particular situation.
• Work out the costs.
• Make the decision based on facts.

Answer 2

Apply the "potentially shippable" rule as far as it makes sense. Use your common sense where it doesn't. (Common sense is sometimes called "rule 0" in agile)

A team should avoid to commit work that is beyond their own power. Translations typically rely on translators outside the team. So the team shouldn't commit to that.

In short: put in your definition of done "Ready for translation".

And reserve some time before the release to complete those little items that are left out of the D.o.D.

For the agile purists (those that interpret it all too literally), that is indeed a tiny little bit of "waterfall". But it works.

Answer 3

Who are the real customers (as opposed to beta users)? Do they expect fully translated text?

If the idea is to let the product bake for a few sprints to get feedback, then you can defer translation so that it is scheduled to arrive in time for final delivery. Otherwise, translate for every sprint; that way the work is "done". If it needs to be changed later, accept that as a cost. The point is not to reduce every single expense at every step; it is to reduce it overall, and make the process more sane and agile.

Further, if your text "will mostly like change" after a few sprints, maybe some effort can be put into choosing better text in the first place, if possible.

Answer 4

Localization should be finished for every release. If you release once per sprint, localize once per sprint. If you release every 4 sprints, localize once every 4 sprints. Have a string freeze period before release where you do not make changes to the strings in the codebase so that your translators have time to update things.

Answer 5

You may run into problems. Assume you need five translators. After a sprint you have one hour worth of work for each. They all work for a third party company. And that company tells you they will not have anyone working for you for less than a day. At one daily pay rate, multiplied by five. So you go to your boss and say “we can have everything completed in the sprint, but it will cost you five daily rates for the translators”.

Instead you check if it is possible to ship a product to an italuan customer that is 90% Italian with 10% English. That makes things a lot cheaper and easier for you.

In your sprint, the task to add some English text automatically includes a task to add or change placeholders in all the translations. A pull request adding a button and not putting a change into all translations must be rejected. And from time to time you book a translator for a week with a task “update French translations” in your sprint.

Answer 6

When something is likely to change, the best way to accommodate this in Scrum is to capture those changes as additional user stories. This is certainly challenging when you need to pay an outside vendor for translation services.

The initial stories for a feature should not include translations as part of the acceptance criteria. Instead, embrace the change that is likely to come. The first story would be written to satisfy the primary language of the application. Additional stories could be created for each translation.

For example, if adding a "Delete Comment" button is the story, then the acceptance criteria would only mention English as the language. Translating the button text to Spanish, German and Arabic would be one or more stories that depend on the first.

Once the "Add delete comment button" story gets released to users, English (or whichever language is the default language for the application) is the language used for the button text. If users request that the button text be changed to "Remove Comment", then create new story: "Change delete comment button text to 'Remove Comment'".

Develop, test and deploy this story. Users give you their approval, and then you can write one or more stories to translate "Remove Button" to Spanish, German and Arabic. This could be one story titled "Translate remove comment button to Spanish, German and Arabic" or create one story per translation.

This implies the stories to translate UI text are dependent on the initial stories written for the default application language. Using the example above, you would have ended up with the following stories:

1. Add "Delete Comment" button
2. Change "Delete Comment" to "Remove Comment"
   1. Translate "Remove Comment" button to Spanish
   2. Translate "Remove Comment" button to German
   3. Translate "Remove Comment" button to Arabic

Where the translation stories depend on Change "Delete Comment" to "Remove Comment". This allows you to delay translation until the default language phrasing has been approved.

Once an application reaches a certain size and complexity, it becomes difficult to make each story releasable after one sprint. You can hide this new button from end users by adding a feature toggle to the application. You would only enable the feature toggle for production once the button text has been approved and translated.

One tiny button ends up being multiple stories, but there is some hidden complexity in code, process and finances. Don't be afraid to bundle a group of stories together as a Minimally Viable Product. Not every story needs to be user-facing after one sprint.