Yves Rocher: Software Support and Business Analysis for the Italian and Portuguese Markets
How Business Analysis Canada supported software work for Yves Rocher in Italy and Portugal, with fixes, changes and business analysis where a change needed it.
- 2 markets with different rules and calendars
- 5 job types, each given the analysis it needed
- 8 areas specified separately for each market
- 1 team for fixes, changes and follow-through
Project at a glance
- Client
Yves Rocher, one of the leading cosmetics brands, with businesses in Italy and Portugal - Engagement
Software tasks and ongoing support jobs for the two markets, with business analysis alongside where a change needed it - Model
A rolling stream of jobs over several release cycles: defect fixes, small changes, market-specific changes, campaign preparation and support on work already in flight - Our role
One team for fixes, changes and follow-through, with analysis applied when a job needed requirements and kept light when it did not - Markets
Italy and Portugal, treated as separate markets, each with different rules, calendars and local teams - Confidentiality
Scope and commercial terms stay under NDA. This case study does not claim any site as built, does not name the technology stack, and does not quote traffic figures.
The challenge
What problem was the client trying to solve?
What did the work involve?
The engagement was a steady flow of jobs for two markets, each arriving at a different stage and needing a different amount of analysis.
- Requests in everyday terms
Local teams raised requests in everyday terms, from "the promo code doesn't work" to "we need a new delivery option before the summer". - Fixes alongside new changes
Some jobs were simple fixes against behaviour that had already been agreed. Others were new market-specific changes that needed requirements first. - Work already in flight
Some work was already in flight when we joined it, with decisions made but not always written down. - Two sets of market rules
Italy and Portugal ran different campaign calendars, promotions, payment preferences, delivery options and invoicing practices. - Fixed campaign dates
Seasonal campaigns meant changes often had a fixed date, so analysis, build and testing had to fit the campaign calendar. - Side effects across markets
A fix in one market could affect the other, so every change needed checking for side effects in both.
Our business analysis approach
How did we approach the engagement?
How did we decide when a job needed analysis?
Not every job started with a requirements document. Each job was triaged first, and the amount of analysis matched what the change needed.
- Defect fix
Example A discount not applying at checkout
Analysis applied Reproduce the issue and confirm the expected behaviour against the agreed baseline
What was produced Defect record with steps, expected result and the regression checks to run - Small change
Example New banner slot or updated text on a page
Analysis applied Confirm scope with the local team
What was produced A short change note with acceptance criteria - Market-specific change
Example A new delivery option or invoicing rule for one market
Analysis applied Elicit requirements with the local team, model the affected process and check the effect on the other market
What was produced Requirements, a process flow and acceptance criteria - Campaign mechanics
Example Gift with purchase, tiered discounts or bundle offers
Analysis applied Write the promotion rules in a decision table and test cases before the campaign date
What was produced Decision table, acceptance criteria and a campaign test plan - Work in flight
Example A change already partly built when we joined
Analysis applied Review what had been decided, fill the gaps and write down the agreed behaviour
What was produced A reconstructed baseline the team could test against
Two markets
How were Italy and Portugal handled?
The two markets shared a brand but not a set of rules. Each was specified on its terms, and changes for one were checked against the other.
Language and content
Italian and Portuguese content managed separately, including product information, usage instructions and legal texts
Campaign calendar
Separate calendars for each market, with change freezes agreed around key campaign dates
Promotions
Promotion rules defined per market, including which offers can be combined and how gifts are added and removed
Payments
Locally preferred payment methods specified per market, with the checkout behaviour for each documented
Delivery
Delivery options, cut-off times and pickup points defined per market
Invoicing
Local invoicing practices, such as capturing a customer's tax number when they ask for it on the invoice
Customer service
Local service processes for returns, refunds and order queries, so changes did not break how each team worked
Legal requirements
Price display, consent and terms reviewed with each market's legal contacts when a change touched them
Work types
What kinds of work ran through the engagement?
Fixes
Checkout, basket, promotion and account issues, traced to their cause and closed against the expected behaviour
Changes
Page updates, new content blocks, form changes, and adjustments to checkout and account journeys
Campaign preparation
Promotion set-up, landing pages and checks before seasonal campaigns, with testing completed ahead of each start date
Market-specific features
Changes needed by one market only, such as a delivery option or an invoicing field
Follow-through
Checking fixes and changes after release, and reopening anything that did not behave as agreed
Documentation
Keeping business rules, decision tables and acceptance criteria up to date as changes were made
Quality checks
How was the work checked?
Fixes, changes and follow-through sat with the same team, so each job was checked against what had been agreed, not against memory.
- Against the baseline. Where agreed requirements or acceptance criteria existed, every fix and change was tested against them.
- When there was no baseline. For older behaviour that had never been written down, we agreed the expected behaviour with the local team first, recorded it, and then tested against it. Each of these notes became part of the baseline for later jobs.
- Regression in both markets. Changes to shared parts of the system were checked in Italy and Portugal, with a standard set of regression checks for checkout, promotions and accounts.
- Before campaign dates. Campaign changes were tested against the decision table for that campaign before the start date, not on launch day.
- After release. Each change was checked again once live, and the local team confirmed it worked for them before the job was closed.
Which BA techniques and tools did we use?
Techniques
- Request triage
- Stakeholder interviews with local teams
- Requirements elicitation
- Process modelling
- Business rules analysis
- Decision tables
- Given/When/Then acceptance criteria
- Impact analysis across markets
- Defect analysis and root cause analysis
- Regression test planning
- Release planning
- Baseline reconstruction
Tools
- Jira
- Confluence
- Miro
- Microsoft Excel
Acceptance criteria
What did the acceptance criteria look like?
Gift with purchase
- Given a customer in the Portuguese store has qualifying products in the basket
- When the basket total reaches the campaign threshold
- Then the gift is added to the basket automatically
- And it is removed again if the basket drops below the threshold
Price reduction display
- Given a product is shown with a discount
- When the product page loads
- Then the reduced price is shown with the reference price agreed with the local legal team
- And the same rule applies on the product page, in the basket and on campaign landing pages
Tax number on the invoice
- Given a customer in Portugal asks for an invoice with their tax number
- When they enter the number at checkout
- Then the number's format is validated
- And it appears on the invoice for that order
Promotion code fix
- Given a promotion code is reported as rejected in the Italian store
- When the fix is tested
- Then the code applies under the rules agreed for that campaign
- And the regression checks for other active promotions in Italy still pass
Day-to-day support
How did support run day to day?
Intake
Requests from the local teams were logged with the market, the page or journey affected, screenshots and urgency.
Triage
Each job was classified as a fix, change, market-specific change, campaign job or work in flight, which set how much analysis it needed.
Priority
Issues affecting checkout or live campaigns came first, then changes with fixed dates, then other improvements.
Release rhythm
Changes were grouped into regular releases, with urgent fixes released separately when needed.
Communication
Each market had a single contact on the team, and status updates went out at agreed points rather than only when asked.
Knowledge
Business rules, decisions and the reasons behind them were recorded as the work went on, so the next job started from what was already known.
Results
What were the results?
- 2 markets with different rules and calendars
- 5 job types, each given the analysis it needed
- 8 areas specified separately for each market
- 1 team for fixes, changes and follow-through
One team handling fixes, changes and follow-through for both markets.
Analysis applied where a change needed it, and kept light where it did not.
- Market differences captured as requirements and rules rather than one-off fixes.
- Campaign changes prepared and tested ahead of key retail dates.
- Older, undocumented behaviour turned into an agreed baseline, one job at a time.
- Changes checked in both markets, so a fix in one did not break the other.
- A growing set of business rules, decision tables and acceptance criteria for each market.
“
Lessons learned
What can other multi-market retail teams learn from this engagement?
- Match the analysis to the job. A text change does not need a requirements document, but a new market rule does.
- Treat each market as a separate set of rules. A shared brand does not mean shared promotions, payments or invoicing.
- When there is no baseline, write down the agreed behaviour before closing the job. Next time, there will be something to test against.
- Put promotion rules in a decision table before the campaign date. Most campaign issues come from rules nobody wrote down.
- Keep fixes, changes and follow-through in one team. The people who made a change are best placed to check it.
Running software changes across several markets?
Talk to a senior business analyst about triage, market rules and support that matches the analysis to each job.
Yves Rocher: Software Support and Business Analysis for the Italian and Portuguese Markets
