As an exercise in the mechanics of an XP project I am creating an instant messaging application. I will attempt to pay attention to the different roles and act accordingly in the different stages of creating the application. My hope is that this can be compressed into a one or two day workshop on XP later on. We’ll see. This is not intended as a description of how to do XP, I am simply trying things out in public for all to see.

First of all we need to take a look at the requirements that we have on the application to develop. Playing the customer, the following user stories where created as a first approach. They are in no way complete, and would in a real world scenario need a lot of refinement. Although I have actually seen less complete requirements in real world applications.

At this point it is important to notice that the user stories are created with no (or as little as possible) regard to architecture or other technical aspects. This is roughly the functionality the customer wants. We have yet to flesh out the details of how things are supposed to work. We will come to that later. The list abouve could be compared to the result of having a requirement workshop (albeit the participants of this workshop don’t seem to be too creative).

The development team on this project does not expect to be handed the complete requirements, ready to develop, by the marketing people. Instead we expect the stories, their priorities, and the scope to be revised several times during the project’s lifetime.

The list above is a screenshot from XPlanner. Each story has an ID, a title, and a priority. I am already feeling myself being guided by a tool. I’m not sure I like that…

Hints of an Architecture

These first approach stories are presented to the developers, who in turn will need a lot of clarification before a plan may begin to form. The features described above do provide a few pointers at the direction the architecture needs to take. A lot of this is still somewhat speculative at this point, so we stay clear of details as far as possible.

• We have at least two user roles: user and administrator.
• We probably need to have a register with all the users of the system.
• We probably need a central server where clients can log on and connect to other users.

With this the team has something to start with. The developers can begin to estimate the stories as best they can at this point, asking for details where those are needed.