The SNCF is France's state-owned railway company. The group employs 272,000 people and generates around €35B per year. On an average day, the train company operates 15,000 trains that transport roughly 10 million passengers around France: a truly massive footprint!
e.Voyageurs SNCF is the subsidiary responsible for the railway company’s ticketing system and online sales platform (Oui.sncf), which processes 110 million tickets per year, accounting for nearly €5B in total annual sales.
At e.Voyageurs SNCF, Anne-Laure Jean supervises product management for two Agile development teams (a total of 17 developers, QA testers, and product owners) that work on complex backend products. Mohamed Moussa is a Scrum Master in one of these teams, responsible for spreading Agile philosophy and best practices across SNCF’s Digital Factory.
As Agile methodologies were introduced to the Factory, product owners were appointed in development teams almost overnight, without them having previous experience in that role. Some of them had a good intuition about which new product features were on the roadmap. Others lacked enough of a big picture view to get a clear understanding of the coming product and technical challenges. This created frustration for dev engineers who often find themselves having to make structural choices in terms of technical architecture without being able to envision all the consequences.
“Did we forget an essential part of the product?” was the question that kept Anne-Laure awake at night. With many inputs from various business owners, she faced a sensitive challenge for sorting things out in a meaningful way without letting key business insights aside.
It became clear that “product owners needed a tool to help get a broader view of which user stories were truly needed to solve midterm product development questions,” said Anne-Laure. By getting all of these details “on paper” in story map form, product owners were then able to provide their teams with the guidance they needed to better anticipate the eventual evolution of the product roadmap.
At that time, developers and QA testers claimed that “during grooming sessions, we only had a line of sight into the user stories coming in the next sprint, but not beyond that,” Mohamed explained. It’s at this point that he encouraged product owners to begin doing User Story Mapping.
Once User Story Mapping was introduced in development teams, “it became clear that it was an ideal tool for helping product owners think in more detail about the products their teams were developing and organize their work in a smarter way,” said Mohamed.
Mohamed has long appreciated User Story Mapping because “it encourages teams to work with a common tool, creating a unique source of truth that helps everyone involved, whether business owners or development teams, finally speak the same language and enables product owners to better grasp the big picture in order to define user stories more wisely.”
The first priority was to map the needs of the entire project. Anne-Laure and Mohamed soon realized that they needed to adapt User Story Mapping to more clearly visualize the “problem space” (business owners) from the “solution space” (product owners).
Then, they put a new process in place whereby business owners were asked to regularly present their needs to the team in the form of User Story Maps and product owners were tasked with their development teams to determine the right solutions to present to stakeholders (not only business owners). The goal here was to create a collaborative and virtuous feedback loop.
In her role as a product manager, Anne-Laure helps business owners ideate and capture future product needs in the form of User Story Maps. And while this new process is, admittedly, on a bit of a learning curve for the entire team, she hopes that “User Story Mapping will progressively become a default tool for product development workflows moving forward.”
“Thanks to product owners and with the help of Anne-Laure, User Story Mapping has unified development teams harmoniously with the other parts of the business,” expressed Mohamed with a great deal of satisfaction.
So, what are the next steps? “We want to standardize the project management process in terms of ‘epics’ between business owners and development teams, in order to help stakeholders be able to follow up project progress more effectively,” explained Mohamed.
By taking advantage of the Jira integration with Draft, Mohamed’s next objective is to “standardize language from management to QA testers and sync up Draft’s epics cards with those available on Jira, to create a genuine, end-to-end continuity in the project management process from decision-makers to doers.”