Last time the customer brought the first approach user stories to the rest of the team. By just looking at them, a few things about the design could be inferred, but the team has not created any architecture or design for the application yet. That doesn’t mean that it is not there. It’s simply not yet documented anywhere yet.

It is now time for the developers to begin estimating the user stories that are presented so far. There are several ways to do estimation. For this project we elect to assign points to each story. The number of points assigned to a user story is an indication of it’s size. A user story with 2 points is estimated to be twice as large as a user story with 1 point assigned to it.

Using the abstract notion of points has a few advantages over simply estimating the time it will to take implement a feature:

• How long something will take is dependent on who is doing it. A team’s ability to perform may change several times during the life of a project. Members come and go. Assignments outside of the project is competing for it’s resources. The size of the stories is supposedly not as susceptible to change however.
• It’s easier to estimate the relative size of one thing compared to another than to estimates its absolute size.
• Estimates, especially at the beginning of a project are just that - estimates. However, over time estimates have a way of being transformed into promises. By using the more abstract notion of points, it can be easier to distinguish between estimates of tasks and estimates of release dates.

Points have some disadvantages as well, the main one being that it is often a hard concept to describe to someone not used to them. “Traditional” estimation includes time rather directly, which is kind of intuitive. With points we only estimate the size of things and expect another concept, velocity, to help us get a time estimate. This may take some getting used to.

For a great exploration into the details of planning agile projects, read Agile Estimating and Planning by Mike Cohn.

Iteration Length

The team should be able to implement each user story within an iteration. This will ensure that the system contains a set of completed features that are of value to the customer at the end of each iteration. To be able to estimate the user stories that fit in an iteration, we need to determine our iteration length. For this project we choose an iteration length of one week. I’m doing this on my spare time, so I don’t expect my velocity to be very high. In a real world scenario the selection of an iteration length should be given more careful thought.

The Stories

Let’s review the user stories so far:

1. A user can send text messages to another user
2. A user can block another user
3. A user can create a chat room and invite other users
4. A user can use a display picture
5. A user can send a file to another user
6. A user can store conversations in a local file
7. An administrator can ban a user
8. An administrator can broadcast messages to everyone

Starting with the first story, let’s consider roughly what that would entail. We need a simple GUI where a user can enter text. We need to be able to discover other users in order to select to whom a message should be sent. We need to log on to a server. We need to be able to store information about users on a server. We need a protocol for discovery and message sending. Etc.

This story seems too big to fit inside an iteration, so we need to split it into smaller stories that can fit inside an iteration. Let’s imagine the team sat down and did just that. This is the result:

• A user can log on to the messaging server
• An administrator can add a user to the server
• A user can list the other users on a server
• A user can send a text message to another user

Now these seem a bit more manageable than the original story. Going through the rest of the stories, we estimate that they all have a decent size. In a real world scenario, we would probably find a couple of more stories that we have problems estimating. In addition to being difficult to estimate due to hiding too much functionality, as with the story earlier, stories may also be difficult to estimate because we don’t know enough about how to solve them. We might, for instance, not know enough about a certain technology. In these cases we might schedule a spike, a time-boxed investigation aimed to give us enough answers to give a good enough estimate.

After going through our stories so far, we end up with the following estimates:

Remember that these estimates only says that we think that story X is approximately twice as large as story Y, and that we believe roughly that we will fit at least one story in each iteration. The story with size 8 might prove to be too large. Or any of the stories for that matter. We may have to revise this later.

With this we should have enough information to start planning our iterations.

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.

I’ve had the opportunity to work in projects that have members in both the U.S. and Sweden, and that has highlighted some differences in cultural background between us that is quite interesting. One of those differences led to some of the U.S. crew commenting on the fact that the Swedes seemed to be in agreement with certain descisions, but when it was time to follow up - nothing had been done.

This view of Sweden is really clashing with the image that we have of ourselves as trustworthy and always trying our best to produce the highest quality at any time. I’m really making generalizations here of course!
The reason for this seems to have been a small difference in cultural behavior between the U.S. office and the Swedish office. During, for instance, a phone conference someone at the U.S. side would ask something along the line of “What do everyone think about this proposal?” or simply “agreed?” In the U.S. culture your expected to jump in immediately if you don’t agree, and express your concerns. In Sweden on the other hand it is quite often the case that if you are in doubt, you want to reflect on the issue before giving a comment. That, at times, led one side of the conversation to think that an agreement had been made and the other side to think that an issue was still open.

This was quite easy to resolve once it was identifed, but it goes to show how very small differences in behavior can have a profound effect on the effectiveness on a team.

I have decided to experiment a bit with the planning aspects of Extreme Programming. I will do this as a one man project, at least initially, so I can explore at my own pace, the mechanics of the planning game and those of the practices that I can manage to use on my own.

I am going to develop an instant messaging application. This is a fairly simple concept, but it is a real world application that I believe will present some challenges.

I will keep the iteration length really short, perhaps one or two days. This way I won’t get bored, and perhaps it is possible to turn this into a one or two day workshop if I can manage to compress the process even more.

I do think that using low-tech tools like a whiteboard and index cards is the best way to get a dynamic working environment in a co-located team. In this case though, I am going to use a tool, XPlanner, to help me with the planning for the following reasons:

• I am doing this from home and I think I will get one or two complaints about the mess if my better half sees a room full of sticky notes.

• Having kids around makes the risk of losing user stories sky rocket.

• At the company I work for, we are located across the world. So, co-located teams are at times not an option.

• I imagine extracting data from a tool like this makes it easier to publish how things are progressing on this blog.

I have just installed XPlanner. I am currently wearing my customer hat and am creating the first user stories, trying to really forget that somewhere deep down I am a developer.

More to come.

A while back I got the opportunity to do some coding together with a colleague of mine that works in North Andover. I am situated in Malmö, Sweden, myself so we had a time difference of six hours to overcome. Using tools like NUnit and FIT/Fitnesse we were able to get quite a good flow even if the circumstances under which we had to work were far from optimal.

A somewhat idealized day could look something like this for me:

When I got in to work I got the latest source, built it, and ran the suite of acceptance tests that we had created earlier. By doing that I got a really good overview of what had happened while I was away from the office. The currently failing acceptance test would act as a marker that showed me how far we were into development. I could also quite easily see the progress since the last day. What new tests were passing that weren’t passing yesterday? Were there any changes to the acceptance tests themselves because my colleague had found some changes in the way things ought to work?

When I had reviewed the changes to the acceptance tests, I could take a look at the NUnit tests that had been added or modified during the night. This gave me a good view of what classes had been modified, and in what way. The unit tests acted very well as more low level documentation on what behavior had been worked on during the night. Now I could do a review of the changes made and see if I could see some refactorings that would make things a bit easier to read and make changes to.

Next, I would turn to the currently failing acceptance test. By starting to look at the code that performed the actual test, I could quite easily get a feel for what needed to be done next - make the acceptance test go a little bit further. I could now go on and start developing the next step, using TDD, and hopefully I could make a complete acceptance test pass.

Around 3 pm CET, my colleague would get to work and we could talk a bit on the phone, or using mail, or IM. During this time we could have a quick design session or discuss some other issues that had come up. After that I could go home, and my colleague could take over for the night.

What struck me when doing this was how much communication the tests were able to facilitate, both the acceptance tests and the unit tests. When the other means of communication where crippled, the tests could make up for a lot more than I had expected.

The acceptance tests:

• Provided a progress bar of sorts on how we were doing.
• Gave enough details on what had been done so one could get a quick overview of what had been done since last time.
• Gave a starting point for today’s work. Start implementing the currently failing feature.

The unit tests:

• Provided the details on what had been done since last.
• Provided low level documentation on any new classes that had been created since last.

When most other forms of communication were limited, it dawned on me how much about communication testing really is. Yes, testing is about asserting that your code behaves properly. Yes, TDD is very much a way to get a good, loosely coupled design. But it is also very much about communication. It is therefore important to keep the tests readable and to the point.

I would also like to get the opportunity to try out some long distance pair programming at some point as well, and see how that goes.

I saw an interesting news report on Swedish TV tonight. Kids in the first grade learn to read by pairing up and writing stories for each other using a computer. It seems that writing is easier to learn than reading. Handwriting, however, is too hard for children to start with, and by using a computer they don’t need to focus on the complicated act of forming letters. That can come later.

I see similarities between this and the agile approaches to software development:

• The creative ordering of what to learn first can be compared to how user stories can be switched around as they are considered independent of each other.
• Starting with the simplest thing first. At first one thinks that one has to be able to read before one can write, but as writing according to this theory is simpler for the children; move that first. This can be compared to the idea about “doing the simplest thing that can possibly work” in XP. In some of the more traditional approaches you almost automatically design bottom up, e.g. starting to design database schemas and protocols because that stuff “just has to be in place first.”
• The children wrote in pairs, seated at one computer, one child writing a story to the other. That’s pair programming for you.
• The children had a lot more fun producing stories, complete with illustrations, than they would have had if they had used the more traditional approach.

A writeup of the news report (in swedish) can be found here.
After some googling, I found out that the method was developed by Arne Trageton.

The articles about Managed DirectX are almost two years old now. They are targetting an old version of the SDK, and may not be valid at all in the latest releases.

I will keep them anyway since people still seem to use them, but I don’t plan to update them or write any more.

The mantra of TDD goes “Red, Green, Refactor!” That is, you write a test that fails, you make that test pass, and then you refactor to remove duplication and other code smells.

It’s a good idea to keep in mind where in the TDD groove one is at each moment, even if the time spent in each phase may be as short as a few seconds. When one has a failing test, one shouldn’t be refactoring. When one is refactoring, one shouldn’t write new tests that fail. This is a good rule to follow, and I always try to follow it meticulously.

One refactoring always make me kind of lost when trying to adhere to the above rule: Extract Class. Most refactorings only touch the internals of whatever class is currently being TDD’ed. Refactorings don’t change the behavior of a class, and should therefore not need new tests. In one sense this is true for Extract Class as well; it does not change the behavior of the original class. But it does, however, create a new class, with it’s own behavior that needs to be tested.

The common way to handle this seems to be to just let things be and let the tests that assert the behavior of the original class indirectly test the behavior of the extracted class. In most scenarios this is probably ok, but the fact that you cannot remove the dependency from the original class to the extracted class without losing test coverage kind of bugs me.

After some discussions about this on the TDD list some embryos for best practices emerged.

• When one is using the original tests to assert the behavior of the extracted class, it may be a good thing to make the extracted class a nested private class of the original class. At least as an intermediate step. This tells the world that the marriage between the two behaviors has not been completely dissolved yet.
• As part of extracting the class, take time to consider what the behavior is that one is pulling out of the original class. Then, look for tests that cover that behavior, and see if it is possible to pull those tests out to a different test fixture. Perhaps after some further refactoring of the tests. Initially, let the new test fixture test the original class. After the refactoring is performed, let it test the extracted class.
• Carl Manaster suggested that triangulation be used when extracting the class. I think this can be used as part of refactoring the tests as well.