Going from use case to customer data platform in 9 steps

Developing a customer data platform (CDP) is a collaborative process that involves close engagement between the customer and Crystalloids. Flexibility is paramount in this process as organizational priorities can change rapidly, requiring us to adapt swiftly. At Crystalloids, we prioritize aligning with our customers and understanding their evolving needs.

To ensure a successful outcome, we place great emphasis on establishing a clear use case that serves as a solid foundation for our work. By defining a precise objective, we can effectively channel our efforts towards achieving tangible results. If you're interested in learning about our approach at Crystalloids, including how we collaborate with customers, craft compelling use cases, and transform ideas into practical solutions, I'm here to provide you with all the details.

1. Getting the use case crystal clear

At Crystalloids, we use the Scrum framework to deliver software. Scrum is a framework within Agile for operating in self-managing teams and is focused on delivering solutions that independently form a working feature, and also are part of a larger product. Our clients often have a high-level idea of what they want to achieve, but do not yet know exactly how to get there. This is where Crystalloids help. If an organization approaches us with a problem or a use case, we will explore it together. We always take the end-user as our starting point. The end-user can have multiple roles. It may be a stakeholder's requirement, but an end-user can also mean someone who will eventually work with a particular piece of software.

2. Defining user stories

User stories are in the center of the whole scrum methodology, telling everyone in the scrum team what needs to be done, for whom, and why. The first session focuses on generating user stories together with a group of stakeholders. Both from the client and from Crystalloids. But before we start we need to make sure that the context of the issues or use case is crystal clear to everyone. Once that is done we start defining user stories in groups. In online sessions, we often use an online collaboration tool like Miro. This allows us to create user stories interactively with a large group on a shared canvas. After each team has created a set of user stories the teams explain the user stories to each other. They ask critical questions about things that are not quite clear. The idea is that at the end of this session you have a list of user stories.

3. Prioritizing the user stories

The next step is to prioritize the user stories. At that point the user stories are still high level, the technology is left out as much as possible. Now, we will introduce the Value versus effort quadrant. User stories are prioritized based on business value and development effort. This helps to add business value quickly. We look at how much a given user story yields the organization in comparison to the investment. The investment can be money, but also time. The user stories that are in the top-left quadrant with have a high value and low effort are then tackled first.

Example of a user story: “As a [persona], I [want to], [so that].”

4. Refining user stories

After the first backlog development sessions, we add all user stories to the backlog of a JIRA project. The next step is to refine the high-priority user stories together with the development team and all relevant stakeholders. We look at the following questions: Is the user story concrete enough? What is the definition of done? In other words, when is the user story ready? Is the context clear? The more specific the user story, the easier it is to estimate and develop. The development team looks at the technical requirements and adds the technical parts to the user story and we are almost ready to start developing.

5. Playing planning poker

With the SCRUM team, we will then assign story points to the refined user stories during a session of Planning Poker. Planning poker is a gamified technique to estimate work using a Fibonacci sequence including a zero: 0, 1, 2, 3, 5, 8, 13, 21. This sequence helps to score user stories relative to each other. Points are awarded based on effort and complexity. Over time you can better compare the user stories with each other. As a team, you have a certain velocity and you know how many points you can pick up with this team. This makes it easier to determine which user stories can be included in the sprint”.

6. Planning the sprint

All user stories that have been refined and have a poker score are ready to be included in a sprint. A sprint is a limited period of time in which work is done on a set of user stories and requirements that together aim to deliver a working piece of software. A sprint usually lasts 2 to 3 weeks, depending on the size of the development team. We will organize sprint planning. This involves the product owner giving input for the sprint. The product owner indicates which user stories have the highest priority. Together with the team, we then consider which high-priority user stories can be included in the sprint. The priority of a user story can change in the meantime. We try to move along with the customers’ needs as much as possible. We first work on the things that are most urgent.

7. Executing the sprint

Once the priorities are set, we get to work. We work with a development environment and a test environment for the customer. Does everything work to everyone's satisfaction? Then the functionality is going into production.

8. Demo

At the end of each sprint, a working functionality is delivered. We show this during the demo. The product owner and other stakeholders will be informed about what has been done during the sprint. We give a short presentation of what has been accomplished. During the demo, we focus on the result, the working software.

9. Retrospective

At the end of a sprint, we always organize a retrospective. During the retrospective, the SCRUM team can share their feedback. This includes points that can be improved, but also positive feedback if something went well. Feedback can be provided on different elements. On the end result of the sprint, but also on other things like the way communication is done or the way things are delivered. After each sprint, we always answer the questions together:

• What went well?
• What could have been done better?
• Ideas
• Actions

Then we plan the next sprint and this creates a cyclical process. We take the feedback with us to the next sprint, to ensure that we work together even more efficiently next time. Working with an Agile mindset and a SCRUM framework allows us to both stay in control and adapt to changing business needs.