PRODUCT BACKLOG
Overall requirements for an agile, iterative, well-described, self-documenting, evergreen, source of truth, compliant, and auditable product backlog.
At minimum, whether in a user story, feature, epic, defect, bug, etc., backlog items should have the following information. I will acknowledge first that this is more information than most are inclined to complete. I will comment on each inline.
NOTE: I will try to make this as tool agnostic as possible, so if the titles/headers do not completely correspond to what your own tool may say, I am assuming that you are able to make the connection on your own.
DESCRIPTION
Current state:
Identify the system’s current behavior or limitation.
Goal state:
Identify what the behavior should be or the goal for this work.
THINGS TO KNOW
Testing notes:
Identify any *weirdness* or edge cases that may be relative to this functionality. This could be company-specific, industry-specific, data-specific, etc.
Risks/dependencies:
Identify any dependencies, internally or externally, and/or risks associated with both leaving the system in its current state or making the changes.
Other:
Identify any other relevant information.
ACCEPTANCE CRITERA
Design:
If there is a mock-up or wire frame associated.
Product requirements:
Identify what the product team wants. Not the implementation, but the REAL WHY. (This is the best place for the traditional “Scrum/Agile” model of “As a [user/role], I need to [perform an action] so that [reason].
Questions:
Identify any outstanding questions. Usually, if there are any questions here, this is not yet ready to work. Sometimes, there are just pending questions that will not impeded starting, and that is fine –if it is captured here.
Feedback:
Comments or notes from stakeholders or anyone, honestly. We are striving for full transparency.
Assumptions:
Identify assumptions made for this work. This could be detailed understanding of a regulation, access to a certain system, pair programming, TDD, following best practices (although that should be the standard assumption), etc.
Technical notes:
For the technical team to put any information that they want to remember and call out, follow up on, or discuss as a larger group.
Technical risks:
Identify risks that are not obvious –and should never be –to the product or business side. They *should* be able to assume that the engineers are doing their jobs correctly.
THE WHY
EXAMPLE: EPIC (or Epic Example, if I do say so myself…)
Epic: Globalization/localization
Description
Current state:
All our applications are currently created for English-speaking, US-locale, users. This was acceptable because, as a rule, most applications are developed with an English UI, and for employment, the cruise industry requires employees to speak English.
While English is an international language, most of our users are not native English speakers. Supporting only English can limit our reach in terms of downloads and users, which automatically means fewer interactions and less than full adoption of our system. This is in addition to confusion in using our applications and in requesting the appropriate support options.
Particularly problematic in our applications is the enrollment process where each onboarding exercise returns with comments of questions from the crew members around address differences in word context.
For example:
"Zip Code" - "Postal Code",
"State" - "Province."
In both of those situations, even the US-based English default is problematic for English-speaking users.
Business use:
Localization (l10n) is the process of customizing an application to work in languages other than the default. Localization can include different spoken variations and dialects of the same language, which are referred to as locales.
Locales are a combination of language and the country in which it is spoken. Think of English spoken in the United States versus Canada or the United Kingdom; or Spanish spoken in Spain, Mexico, and Argentina. Locales are most often named using two letters indicating the language, followed by two letters indicating the country.
For example:
en_US: English - United States
en_CA: English - Canada
en_UK: English - United Kingdom
fr_FR: French - France
fr_CA: French - Canada
Further, by adding multi-language support, our applications can show up in the application stores in the user's language. That capability automatically increases the app's MAU (monthly active users).
According to research, applications experience an average 128% growth in downloads and usage and a 26% increase in revenue for each country added ONE WEEK after adding localization.
To maximize our adoption and potential future reach, we need to extend our applications to serve different users in different regions with different preferences with application localization.
Risk:
Existing language embedded in the application must continue to work throughout. Clients should see no differences in the UI experiences until a locale is fully launched.
Things to remember:
Each application has a different recommended approach for localization. The set of strings and text will need to be consolidated and kept up to date with the existing strings until full launch. (This is an opportunity to gain consistency as well.)
Different languages will require more or less of currently designated screen space. Ideally, our applications would be tested for readability across the limits at both ends of the spectrum. The web application should be responsive and optimized for mobile viewing.
The IDs associated with each localizable attribute will need to be consistent across all applications, and the dictionary for use will be centrally located.
Memory and performance of the applications must be considered and held in mind for each approach considered and implemented.
Localization does not only apply to the text displayed. It also applies to the logos and images that may be displayed throughout. Those should also support localization.
Zendesk integrations must be supported as well.
Our integration partners and steps may or may not be able to handle multiple locales. We will need to have an approach for either situation.
What we are going to do:
Collect all strings and assets used in each of our applications –all of them, not just our externally visible ones.
Consolidate all the strings and assets in use and determine whether we need to engage a third-party for translations or if we would like to use the crew.
Determine the data (probably from our IIS logging to the database) to determine the device types and each OS in use with our applications.
Review data from the mobile application stores to determine the device language settings for our existing downloads.
Obtain metrics from research of real crew members as to whether the device that they currently use is their preferred device or if they are using those devices as workarounds currently.
Work with analytics and marketing to determine the breakdown of locale information, possibly using passport origin information in our current enrollments. Use that data to determine an initial additional language to implement.
Determine method of mobile application localization. –There are two widespread methods with the first one being slightly more so:
1. Let users select the language in the device's setting.
2. Let users select the language in the application itself.
Internationalize our applications.
EXAMPLE: FEATURE
Feature
Summary
To support localizing the application for a user, not only text should display in their language, but any date and currency should display in the format of that specific language/location.
Current State
Dates and currency formats are either hard coded on the application side or hard coded in the API.
Business Case
To reach a broader audience, we want to be capable of presenting the application to the user in their own language.
Risk:
Existing language embedded in the application must continue to work throughout. Clients should see no differences in the UI experiences until a locale is fully launched.
Feature flag details
Key:
Description of on/off behavior:
EXAMPLE: USER STORY
User story: (Android) Collect and store resource assets
Description
As preparation for localization and management of the copy, we need to collect all the resource assets (strings, messages, images) in use in all of our applications.
Currently, our applications are in various stages of removing the embedded, hard-coded text in use, for messaging to users, labels, help text, labels, etc. To be able to make our applications consistent with each other and the message from the company as a whole, we need all of these values and assets to be collected externally in a file that will then be shared among all of the platforms.
This is inclusive of both the web, React, Android, iOS, and APIs, and includes all hard-coded text and images.
When these assets are collected, we can reconcile the lists against the copy that is recommended, have all reviewed for marketing, compliance, and best practices. It will also allow us to begin having the resources translated to be implemented at a later date.
For this effort, the only risk is in missing any of the values and regression testing.
NOTE: There is no external dependency here because this is only working to remove the hardcoded assets already present. Subsequent stories will address the consistency and further refactoring.
NOTE: There is a plug-in that will make this work "brainless," so it is not as manual as one would think. Please see Kristen.
NOTE: The location of these files ultimately is irrelevant, as they are working files. To that end, the files should be located on the company's OneDrive space, under the designated folder for the Engineering team's localization work.
NOTE: The format of these files is also unimportant at this point. Each can be in whatever format allows it to *work* in its respective application / platform. It must contain the key, value, and a description identifying the context of each value's use, at minimum.
Comments