Embarking on the journey of digital transformation: An agile experience with CHRIST

Abstract

This teaching case explores the digital transformation journey of CHRIST Juweliere und Uhrmacher seit 1863 GmbH (CHRIST), a historic jewelry company adapting to a digital retail environment. CHRIST has partnered with the consultancy KPS AG to enhance its e-commerce and marketing capabilities using agile methodologies, specifically the Scrum framework. A central focus is the requirement engineering process, which ensures the alignment of business needs with technical solutions. This teaching case examines how CHRIST identifies, documents, and refines user stories to create a structured product backlog. It highlights the collaboration between business and development teams to clarify requirements, set priorities, and manage scope changes. It delves into how CHRIST and KPS collaboratively manage the intricacies of digital transformation, ensuring alignment across multiple project streams and leveraging external expertise to drive innovation. Students will gain insights into the complexities of requirement engineering, the benefits of agile project management, and the strategic approaches necessary for successful digital transformation in a multi-channel retail business.

Introduction

Traditional brick-and-mortar retailers are at a crossroads in an era of unprecedented technological advances and changing consumer behavior. The rise of e-commerce giants and the proliferation of digital shopping experiences have reshaped the retail landscape, challenging established players to adapt or risk obsolescence. This teaching case explores the digital transformation journey of CHRIST Juweliere und Uhrmacher seit 1863 GmbH (CHRIST), a jewelry company grappling with the need to adapt to an increasingly digital landscape. Founded in 1863, CHRIST has upheld a mission centered on inspiration and timeless craftsmanship. Located in Hagen, North Rhine-Westphalia, Germany, CHRIST serves as the nucleus of the CHRIST Group, uniting more than 200 dedicated individuals committed to maintaining high quality and customer satisfaction standards. With a workforce of 2000 employees in Germany and Austria, the CHRIST Group encompasses a diverse portfolio, including CHRIST Juweliere und Uhrmacher seit 1863 GmbH, VALMANO GmbH, and CHR Logistik & Service GmbH, which operate in the European jewelry and watch sector under the retail brand’s CHRIST, VALMANO, and BRINCKMANN & LANGE (CHRIST, 2024b, 2024d) (Figure 1).

Figure 1.

CHRIST’s online shops.

This teaching case invites readers to delve into the intricacies of CHRIST’s digital transformation journey, examining the challenges and outcomes of the company’s e-commerce and marketing project. Participants will gain valuable insights into the complexities of requirement engineering in digital transformation projects.

A journey through 160 years of CHRIST

Longstanding businesses hold a distinct position in the dynamic realm of continual change, and CHRIST exemplifies this resilience. With a legacy spanning 160 years, CHRIST has earned the trust and loyalty of its customers, reflecting on its heritage and dedication to excellence. Founded in 1863, CHRIST has remained a steadfast champion of fine jewelry and watchmaking, renowned for its impeccable craftsmanship, superior quality, and enduring elegance. CHRIST directly controls its entire production chain. CHRIST ensures high product quality at the best market prices by sourcing diamonds and gemstones directly from the mines and manufacturing them in-house. On February 1, 2023, the CHRIST GROUP entered a new chapter in its 160-year history by becoming part of the Morellato Group, Italy’s largest jewelry and watch company, founded in 1930. With a combined presence of over 620 stores and a unique digital footprint, the collaboration aims to strengthen its leadership in European markets. This prestigious family-owned company allows CHRIST to continue its traditions while synergizing its strengths. Massimo Carraro, the former CEO of CHRIST and President of the Morellato Group, emphasizes the exciting future that comes with being part of a large family that shares traditions and values. The Morellato Group encompasses various jewelers as well as jewelry and watch manufacturers. With a revenue of approximately €370 million in 2022 and more than 2500 employees, it represents a unique European business model covering the entire jewelry and watches supply chain, brand management, and wholesale and retail operations (CHRIST, 2024a, 2024c).

Project background

For several years, CHRIST has been enhancing its digital services with the support of KPS AG (KPS), a German consulting firm specializing in digital transformation and business process optimization. CHRIST and KPS have collaborated for 14 years, particularly in e-commerce and, more recently, in marketing, ensuring a personalized customer journey across all touchpoints. The marketing project involves migrating to a new system for better channel availability, data management, and usability.

Jack from KPS is the project manager and product owner for the e-commerce project, working closely with Nicolas from CHRIST’s e-commerce IT project management team. Lea leads the marketing project, which is preparing for a go-live event for the new marketing system. Both projects follow an agile approach using the Scrum framework, illustrated in Figure 2, which emphasizes iterative development, collaboration, and continuous improvement. Scrum involves a time-boxed approach, typically in two to 4-week sprints, where a cross-functional team works on prioritized tasks. Scrum includes key roles (Product Owner, Scrum Master, and Development Team), ceremonies (Sprint Planning, Daily Standup, Sprint Review, and Sprint Retrospective), and artifacts (Product Backlog, Sprint Backlog, and Increment). The framework promotes adaptability, transparency, and continuous improvement to deliver valuable and high-quality products (Scrum.org, 2024).

Figure 2.

Scrum process in the CHRIST project (based on Scrum.org, 2024).

Jack and Lea are the Product Owners of their projects. Their teams on the KPS side act as the development team. On the CHRIST side, Nicolas’ team does not directly correspond to a Scrum role. As several teams are involved in the project, their role is to manage the product and sprint backlogs to ensure that the user requirements have all the necessary information and to prioritize, decide, and moderate which stories will be implemented in the sprints. They, therefore, act as an interface to other teams that work directly or loosely with the webshops. An overview of the teams is shown in Figure 3.

Figure 3.

CHRIST’s team structure.

Both projects are managed using Atlassian’s tools Confluence and JIRA to structure, organize, and manage communication throughout the requirements implementation process. JIRA is a project management and issue-tracking tool that facilitates efficient work planning, tracking, and management, particularly in agile methodologies. Confluence is a collaboration and documentation tool for creating, sharing, and collaborating on content, including wikis, documentation, and meeting notes. Both projects share the same toolchain but are managed operationally separately. As shown in Figure 4, JIRA and Confluence are linked through application integration, allowing seamless communication between the two tools. Users can embed JIRA issues in Confluence pages and link Confluence pages to JIRA issues. This integration streamlines project management and documentation, improving team collaboration and efficiency.

Figure 4.

Confluence & JIRA usage (based on Herrmann, 2019).

From business need to feature

It all starts with a business need. Maria, the Business Operations Manager, approaches Nicolas. The idea is described as follows: “Don’t you think it’d be amazing to have a digital wishlist? A place where you can save all those products you’re eyeing? Imagine when your birthday or Christmas rolls around; instead of receiving generic gifts, your loved ones could pick something straight from your wishlist, making every gift truly special! You should be able to easily add products from both the overview and detailed product pages, with clear images, prices, and all the necessary details. And wouldn’t it be handy if you could easily manage your list, deleting items or the entire list with a simple click? Of course, adding items directly to your shopping basket should be a breeze, too!”

Nicolas instructs Maria to create a “user story” in JIRA, which is a concise, informal description of a feature from an end user’s perspective, typically formatted as: “As [type of user], I want [an action] so that [benefit or goal] is achieved.” Maria creates the user story, adds a UX designer’s screenshot, and places it in the “product backlog,” which collects all requirements in this structured form. Jack reviews the story but finds it lacking details such as sizes, colors, mobile behavior, wishlist access, and whether individual or entire wishlists can be added to the shopping basket. He also suggests saving the list upon user login. Finding these details missing, he sends the story back to Maria, and they arrange a meeting to address the issues. Maria realizes the task is more complex than she initially thought.

Jack invites Clara, a developer, the UX designer, and Maria to a meeting. To prepare, he creates a specification page in Confluence, detailing Maria’s requirements and open questions. During the meeting, they collaboratively fill in the gaps, and the UX designer shares a link to the UX tool for Clara to access design information. After the meeting, Maria updates the user story structure to document all requirements, including descriptions, “acceptance criteria,” and “definitions of done” (DOD). Acceptance criteria outline specific conditions for a user story to be considered complete and accepted by the product owner or stakeholders, covering functionality, performance, and other requirements. The DOD is a set of criteria that must be met for a task to be considered complete and ready for release, including coding standards, testing, and documentation. Following the requirements engineering process, a refinement meeting is held to ensure that all user stories meet the criteria and agree on priorities. Jack, Nicolas, and the development team attend this regular meeting, which always occurs before the sprint starts. In addition, selected people can join the meeting as well if necessary. A sprint is an iteration of fixed length during which a development team completes a set of user stories. The scope is fixed for the duration, and the goal is to deliver a potentially shippable product increment by the end of the sprint. Based on priorities and resource capacity, the user stories for the next sprint are selected and transferred to the sprint backlog. They are now the fixed scope (sprint goal) for the next sprint, which runs for 2 weeks. The developers working on the user stories use a PULL system, meaning each developer can decide which story they want to work on by assigning it to them. Daily standups are used where developers give a short status of their stories and highlight potential obstacles. In addition to the short daily standups, a longer weekly meeting is held at the end of each week to answer upcoming questions and coordinate open issues in preparation for the next sprint. A sprint board is set up in JIRA, as shown in a simplified version in Figure 5, to track user stories.

Figure 5.

JIRA board setup.

Initially, all issues are in the “TO DO” queue. When a developer starts working, the user story moves to “IN PROGRESS.” After implementation, the developer tests it and checks acceptance criteria and the DOD. Then, the ticket moves to “CODE REVIEW,” where another developer reviews the implementation. If it meets all standards, the story moves to “QA READY” (QA = Quality Assurance) for testing. Once testing starts, it’s moved to “QM APPROVAL” (QM = Quality Management). After quality management testing, it goes to “TEST & APPROVAL CHRIST” for CHRIST’s business user’s final testing and approval. If successful, the issue is closed in the “FINISHED” queue. If any failure occurs, it goes back to “TO DO,” restarting the process. It is important to add that testing can be done as soon as the feature is implemented and there is no need to wait for the end of the sprint.

Back to Maria’s user story: The wishlist requirements are delivered 2 days before the end of the sprint, giving Maria time to test the feature. She opens the user story and opens the website. She adds and removes products from her wishlist, running through several user scenarios and checking that all acceptance criteria are met. Satisfied that everything works as expected, she moves the story to the “FINISHED” lane. Maria then presents the new feature to the team. Weeks later, marketing manager Thomas approaches her with new ideas for using the feature in marketing communications.

Aligning requirements with multiple projects

In contrast to the e-commerce project, the marketing project is currently in the process of switching to a new system. The aim is to migrate from Episerver to SAP Emarsys by transferring contact and permission information from the old to the new marketing system and to recreate current marketing processes such as newsletter registration and the welcome email after registration.

Thomas wants to use the information from the wishlist in his marketing campaigns: “I believe it’s important to listen to our customers and honor their preferences in our marketing efforts. Imagine if we could surprise them by sending their wishlist when they haven’t made a purchase yet, gently reminding them of what they liked. And what if we could also remember special occasions like birthdays or holidays, sending them a thoughtful reminder with tailored recommendations? We should ensure the list is always up-to-date with the latest products, prices, and options, and maybe even suggest items from similar collections or designers to enhance their selection. It’s all about making our customers feel valued and offering them something special, especially when we have exciting offers or promotions to share.”

Thomas envisions several marketing uses for wishlist information. In projects, teams often aren’t aware of all current issues and requirements, making prioritization essential. In CHRIST projects, legal requirements and major errors are the highest priorities. Legal requirements demand immediate action due to regulations, while major errors that disrupt crucial business processes, such as purchasing, are also top priorities. Other issues are prioritized based on their business value. For example, improving the checkout process might increase sales, while minor features like a new button design may have less impact. The implementation effort, budget, and resources, assessed by project managers Lea and Jack, also play a role in deciding which user stories to include in a sprint. To structure this process, an annual roadmap is created with all stakeholders to plan major topics for the year in alignment with CHRIST and KPS. This roadmap helps identify dependencies, plan further alignments, and get early buy-in from everyone to ensure successful delivery. In addition, project managers attend each other’s weekly meetings to stay informed about progress on shared features. For wishlist integration, e-commerce and marketing teams must ensure seamless data transfer and correct data reception. Joint weekly meetings are held to update both teams and coordinate integration testing.

With the upcoming go-live, Thomas agrees to a compromise. The interface extends to send real-time product wishlist information to the marketing system. This data includes details like which products are added and their prices, allowing Thomas to send targeted marketing communications based on customer preferences. However, importing historical wishlist data is not included in this phase, meaning products saved before the new feature won’t be sent to the marketing system. This additional data would help identify customer interests and enhance recommendation engines, suggesting related products. Due to limited human resources and the absence of key personnel on holiday, importing historical data is postponed to a later sprint. Thomas creates a user story for this task, which remains in the product backlog and is planned for the second sprint after going live. Resource bottlenecks are common in projects due to limited availability, dependencies on critical resources, competing priorities, and inefficient use of resources. To manage this risk, Lea plans to align resource requirements with all involved parties and involve key stakeholders in refinement meetings. This ensures that they can veto if parallel projects or holidays interfere with the planned sprint scope. By implementing this strategy, Lea proactively identifies, mitigates, and manages resource bottlenecks, ensuring successful project outcomes with minimal disruption.

Dealing with changing requirements

Other use cases are being considered once the marketing system is running. Thomas is working with Maria to integrate product recommendations from the marketing system into the website, which he has already used for email marketing. These recommendations, based on browsing behavior and purchase history, are expected to enhance user experience and increase engagement, conversion rates, and revenue. The new marketing system offers several algorithms, like “related products” and “recommended for you.” Maria and Thomas define which algorithms to use in specific placements, such as “related products” on product detail pages and “recommended for you” on the home page. They create user stories for each placement to ensure proper implementation, refining, and scheduling the tickets for the next sprint.

During the sprint, Maria receives a report showing low-margin conversions from recommendations due to pricing strategies for certain brands. To improve this, she decides to add a filter to exclude low-margin brands from the “recommended for you” logic. She approaches a developer working on one of her tickets, and he agrees to implement the filter after receiving a list of brands to exclude. The next day, the developer reports in the daily standup that modifying the algorithm is more time-consuming than expected. Jack is unhappy because additional requirements should be planned for the next sprint or agreed upon with him as the product owner. Since this change was not planned, another task might not be completed. Jack tells the developer to direct Maria to him next time for reprioritization and scope agreement.

After the daily meeting, Jack and Lea approach Maria and Thomas to agree on handling requirement changes. Maria is unaware of the implications of her request but agrees to follow Jack’s suggested process. During the meeting, Thomas mentions a customer complaint about recommended products being out of stock or having long delivery times. To address this, Thomas proposes showing only products with at least 20 items in stock and a delivery time of 2–3 days. Realizing this would increase the scope, they review the sprint backlog and prioritize adding the availability filter. They replace some recommendation features from the current sprint with this new requirement, ensuring no work has started on those features, and link the new user story to related stories. Regarding the delivery time rule, Maria decides to consult internally before creating a new requirement. Jack then informs the development team about the scope changes.

CHRIST’s digital journey—moving forward

One of CHRIST’s future focuses in its digital journey is on customer relationship management. With a large and loyal customer base, CHRIST aims to deepen relationships by offering more services and benefits to long-term customers. Loyalty management is key, helping to retain customers, increase their lifetime value, and foster long-term relationships. By rewarding loyalty with incentives, personalized experiences, and exclusive offers, CHRIST can strengthen brand loyalty and encourage repeat purchases, standing out in a competitive market.

A/B testing is also crucial, allowing data-driven decisions by comparing different versions of a web page or feature to see which performs better in terms of conversion rate, click-through rate, or user engagement. Testing variations in layout, design, and functionality helps UX designers improve user experience, satisfaction, engagement, and retention. It identifies effective strategies for increasing sales, generating leads, and encouraging user interaction, enabling continuous optimization and reducing risks associated with changes. For example, past tests revealed that CHRIST.de customers prefer different features than VALMANO customers, who have a younger, more experimental audience. This allows tailoring of user experiences based on preferences and behaviors. Segmenting users and testing personalized content or offers lead to higher conversion rates and customer satisfaction. This approach fosters a culture of continuous improvement through experimentation, learning from feedback, and iterating on changes to optimize website performance and customer experience.

CHRIST looks forward to a future that combines the offline and online worlds, offering excellence in products, services, and journeys. As the company itself says: “We are ready to continue our tradition of excellence.”

Suggested discussion questions

1. Explain the agile methodologies employed by CHRIST in its e-commerce and marketing projects. How was the Scrum framework adapted, and why?

2. How do agile methodologies enhance project flexibility and responsiveness?

3. How do partnerships, such as the one with KPS AG, contribute to CHRIST’s digital journey?

4. What are the benefits and potential drawbacks of acquiring external knowledge?

5. What role does requirement engineering play in CHRIST’s digital transformation projects? How does the company ensure alignment across different project streams?

6. Identify the requirements for the wishlist feature. Develop user stories for these requirements.