How can you prioritize features and requirements in Extreme Programming?

Although many digital platforms exist to document and organize user stories, index cards were also used to document them. The physical size of an index card helped to limit the amount of text being recorded, but also some customers enjoyed having something physical to pick up, read, and manipulate when participating in XP's prioritization and release planning processes. Having limited space on an index card might be seen as a disadvantage, but it forced the description of customer features to stay concise and focused on what was going to deliver value.

Giving customers an active voice when deciding which features to deliver and in which order can be empowering and eye-opening, but don't underestimate the effort needed to 'pull them down into the details' more. Customers that are used to just 'taking delivery' of one complete system or another are now expected to have an opinion about the bits they think should be delivered earlier or later in the process. Customers that are not used to having input at this level of detail may feel overwhelmed, especially when requirements get technical, and will rely heavily on developers or the facilitator to help them through this part of the process. Still, it can feel amazing when customers buy into a release schedule after having contributed to it.

Although the MoSCoW Method is referred to as a prioritization method or framework (I don't believe it's specific to XP), it's still useful to think about *how* user stories end up in one or other of those columns. In other words, what you're trying to optimize for will actually determine what you Must, Should, Could, or Won't build. For example: a desire to untangle technical dependencies earlier rather than later might suggest you (Must) develop login functionality before anything requiring authenticated access; a riskiest-first approach might be taken to ensure the technical feasibility of the system being considered; or a value-first approach could be adopted which seeks to release the most value in the shortest time possible; etc.

My biggest takeaway from having used XP many years ago is to make sure it suits the culture and environment of the team/organization you're working within. XP seeks to elevate the voice of your customer (the user of your software) and places a lot of emphasis on face-to-face feedback, continuous feedback loops, transparency, and commitment to undertaking a journey where risk and value are shared. The time and effort needed to engage with customers, well, throughout this journey shouldn't be underestimated, and some development teams, and some customers, will struggle with this model. Done well though, the collaboration can feel amazing.