Technical practices such as Pair programming, Refactoring, Test Driven Development and several others are part of XP or came from teams that used XP in the past.
The most natural process is that your team starts with Kanban or Scrum and then the need of improvement arises.
In that moment Extreme programming comes in. So, they start exploring.
Neither Scrum, Kanban or XP can provide concrete guidance about the looks of the product, or how to make decisions.
Scrum defines a role to cover some of these tasks to the owner of the product – but does not give much understanding of how to do this work, except how this function works in the rest of the Scrum structure.
Teams have found field practices such as product management (product ownership is a subset), user experience and business analysis that fills the void. Inspired by technology from these areas, people from the flexible community have developed methods such as a Project Chartering and Story Mapping.
Situations are different, depends a lot of the organization in the matter. Your situation is also going to be different one year later as the team increases because of the improvement, new projects can lead to get different members for your team.
The way your team decides to deliver the product will differ from other organizations too. Structures such as Scrum, XP and Kanban give good starting points for your team to develop their methodology, but you need to find out what works best in your context.
This means that do not be afraid to use aspects of different structures if you understand why. It also means that you will need to supplement these structures with other methods.