Product Owners, Scrum teams ... WHY CAN'T WE BE FRIENDS?
Last Tuesday 9 am it was a special day. A day that I've been waiting for a long time.
Last Tuesday it started my training to work towards my Scrum Master certification. I’ve been involved in the last years in projects using the Scrum framework. However, what I wanted to achieve with this training was not really the certification, what I was looking for it was some inspiration and also more details from the insiders about how the Scrum teams work.
Some picture I took during the course, including our User Story to create the next blockbuster in the gaming industry: Angry but cute-sheep :)
In that sense, I’m happy that I found interesting food for thoughts during last week. And I got a couple of ideas that I want to explore further here in my post.
Ideas that it might help Localization teams to achieve one of our most desired desires.
This mystical and elusive desire that the Localization community is pursuing is no more any else than having localization activities involved earlier in the development phases.
Every Localization colleague I met during my career expressed this desire in different ways. Usually, the challenge we face as Localizers is that localization quite often is an afterthought. Something that some teams see as a tedious task. Something that they “have to do” but that they don’t really see the value. So, obviously in this mindset where Localization is considered an “after” activity the desired to be put earlier in the process is exactly that … an obscure object of desire.
So which are those 2 ideas worth it to explore? Which are those ideas that I found that it might help us to have Localization activities happening much earlier ??? Keep reading, hope this might be also some food for thought my dear blog readers ...
1.-Product Owners can be Localization BFF!
The role of the PO (Product Owner) is quite critical in any Scrum team. To make it simple they are the glue between different stakeholders and they have the responsibility to define the vision of the product, they need to inform regularly project sponsors and they manage the product backlog ensuring that useful features are incrementally shipped in every release.
Why do I believe that PO can be Localization BFF (best friend forever)?
The reason why I believe PO can be Localization BFF is that they are the person in charge of learning about the business needs and understand how the product improves the business.
This task is at the core of the work any PO does; and what’s something that a PO can learn which it might help the product to improve the business? Bingo! The answer is learning about how Localization/Globalization teams can help Scrum team to bring more value to the app/game/software being developed.
There’s a very visible connection between investing in Localization and improving the revenue (if you need some context about this please check my post about metrics HERE).
For this reason, if we, as Localization experts, spend time with PO to help to understand how Localization fits nicely to meet this core value of their job, we might be in a good position to be involved earlier.
Also POs are responsible for maximizing the value of the product and the work of the development team, so what if Localization can help POs maximizing the value of the product by being very clear about how localizing the product will help to increase the revenue?
Localization usually is a stakeholder of any product being developed, and POs are responsible for identifying and building relationships with stakeholders, Ta-chan! Dots connected! POs can become an effective Localization ally if we as Localization team go to the point and we are able to express clearly how Localization boosts global sales.
If we succeed in explaining this what it might happen is that we see that Localization can be part of the product backlog, and that’s a good place to be; because the PO is the sole person responsible for managing the Product Backlog.
So action number 1 and food for thought from my Scrum Master training: work to establish a strong relationship with POs and evangelize about the benefits of localizing their product in multiple languages.
2.- Include Localization in user stories and in the definition of Done
User Stories are quite important in the Scrum world. So, let’s go with a short definition before moving forward.
User stories are one of the primary development artifacts for Scrum teams. A user story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it
A User Story is a good way to remind that we need to have a conversation with different stakeholders. It’s basically a reminder that we need to do something at a high level just in time.
So, if User Stories are important …. and if user stories are created at the beginning … maybe the quickest shortcuts for Localization/Globalization teams to be involved earlier in any development product cycle is exactly that. It’s being visible in the user stories.
User stories are simple enough that they can be written in a few minutes and once they are written they can be managed as a product requirement.
Let’s take the following example I wrote to illustrate better my point here :)
User story dedicated to my lovely Japanese colleagues :)
If I’m part of a company developing a new game that it will be launched globally, sooner or later the game team will come to me as Localization Specialist to work on the globalization strategy to release the game, let’s say in Japan.
If at the beginning I create this User Story …. And if I work with the Product Owner so s/he understand how important is to internationalize properly the code from the beginning, that will have a huge impact on later localization phases.
Let's go one step back and let me remember you the Internationalization (I18n) definition. I18N is everything we do to ensure that products can be localized easily later. This means that products are adapted so everyone can use them later in different global markets. Implementing basic I18n best practices will help us achieve a more flexible source product and one that is ready to go global. If you are a developer externalizing strings, implementing font properly or create a dynamic UI should be at the top of your I18n To-Do list.
My point here is :
“What if we convert the I18N best practices listed below in part of the user stories?”
And let me take these thoughts one step further.
“What if we include proper I18N as part of the definition of Done?”
The idea of Done is quite important in the Scrum world. What “done” means here?
Each Scrum Team has its own Definition of Done, but basically is a consistent acceptance criteria across all User Stories.
A definition of done can be a checklist of necessary tasks implemented to ensure that only truly done features are delivered.
A Definition of Done drives the quality of work and is used to assess when a User Story has been completed.
Definition of done is crucial to a highly functioning Scrum team.
Going back to our example of the Japanese player in the user story Done might include some definition aligned with the following checks :
Since Chinese, Japanese and Korean may require a larger font size in order to be read. Therefore it is important for the DevTeam to accommodate this vertical expansion as well.
Roles, responsibilities, and examples:
• UX: Design game layout screens to accommodate text expansion and contraction in both length and height. This may require a different CSS for some languages.
• Developer: Code to accommodate not only the visual expansion designed by the UX/UI, but also recognize that there will be a byte expansion with the use of multi-byte characters.
• Tester: Ensure the translations fit correctly visually and/or audibly. This should be done prior to actual translation by using a pseudo translation. Check text entry fields to ensure proper handling of multi-byte characters.
In my opinion if we include Localization as part of the Use Stories and if Include Localization checks as part of Done we are going to have a more stable product and we are going to have a much more high quality product.
And if you are not convinced that proper localization, internazionalization and planning is important for any software development activity … maybe this video can help to change your mind :)
So what you do you think Product Owners and Scrum people? Can we be friends? Even better ... Can we be Best Friends for Forever? We are ready to extend our hands :)
Have a wonderful w-end! and do your best to be happy!
@yolocalizo
Localization is all about adapting content from one culture to another, from one market to the next. The tricky part is the thin line separating appropriation and appreciation. The challenge is to adapt content respectfully and give proper credit. It's easy to blur the line between appreciation and appropriation. My post this week reflects on that.