Share this
Going from use case to customer data platform in 9 steps
by Kevin Kriek on Oct 11, 2021 1:20:05 PM
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.
Share this
- September 2024 (1)
- August 2024 (1)
- July 2024 (4)
- June 2024 (2)
- May 2024 (1)
- April 2024 (4)
- March 2024 (2)
- February 2024 (2)
- January 2024 (4)
- December 2023 (1)
- November 2023 (4)
- October 2023 (4)
- September 2023 (4)
- June 2023 (2)
- May 2023 (2)
- April 2023 (1)
- March 2023 (1)
- January 2023 (4)
- December 2022 (3)
- November 2022 (5)
- October 2022 (3)
- July 2022 (1)
- May 2022 (2)
- April 2022 (2)
- March 2022 (5)
- February 2022 (3)
- January 2022 (5)
- December 2021 (5)
- November 2021 (4)
- October 2021 (2)
- September 2021 (2)
- August 2021 (3)
- July 2021 (4)
- May 2021 (2)
- April 2021 (2)
- March 2021 (1)
- February 2021 (2)
- January 2021 (1)
- December 2020 (1)
- October 2020 (2)
- September 2020 (1)
- August 2020 (2)
- July 2020 (2)
- June 2020 (1)
- March 2020 (2)
- February 2020 (1)
- January 2020 (1)
- December 2019 (1)
- November 2019 (3)
- October 2019 (2)
- September 2019 (3)
- August 2019 (2)
- July 2019 (3)
- June 2019 (5)
- May 2019 (2)
- April 2019 (4)
- March 2019 (2)
- February 2019 (2)
- January 2019 (4)
- December 2018 (2)
- November 2018 (2)
- October 2018 (1)
- September 2018 (2)
- August 2018 (3)
- July 2018 (3)
- May 2018 (2)
- April 2018 (5)
- March 2018 (5)
- February 2018 (2)
- January 2018 (4)
- November 2017 (2)
- October 2017 (2)