Last time I did a rough estimation of all user stories supplied so far. In addition the iteration length was set to one week. This time I am going to plan the work for the near future. I may even come up with a rough estimate for the final release.

Ruby

To throw some risk and uncertainty into the mix, I have decided to implement the application in Ruby. I have never worked with Ruby before, and I will address this by adding time-boxed investigations to the plan where needed. Normally, I would probably spend a lot of time up front learning a new technology or language, trying to find all the really cool features of the language so I would be able to take advantage of them from the beginning, but this time I am going to add targeted investigations throughout the development plan. These investigations will be targeted at solving a specific problem or giving enough detail to implement a user story.

The rationale for doing it this way is to see how it works to take a big unknown, or risk, and instead of addressing it as much as possible upfront, address it when needed at different times during the project. It will force me to investigate just enough for the problem at hand, and make me implement features the simplest possible way I can. So be prepared to see a lot of Ruby code with rookie mistakes!

The First Iterations

At this stage I think it is time for the customer to make some decisions about in what order the user stories should be implemented. So, putting my customer hat on, I try to think about what I want to see from the application in its first incarnations. The most important aspect of this application will be the messaging interface; how the user interacts with the system while writing and receiving messages. So as the customer I determine that I want to see the user story “A user can send messages to another user” implemented first. I want to see the GUI for exchanging messages with another user up and running so I can give some feedback on that as soon as possible.

As the developer, I suggest that we add some investigations into Ruby in the first iteration, and that it may be too much to both get the hang of basic language features and GUI support at once. I suggest that we compromise and implement the story with a simple console front end at first, and then tackle the GUI.
As the customer, I am not overly excited about not getting the first crack at the GUI at once, but I trust the developers when they say that the cost for adding a richer GUI to the mix now is too high. But I do want that GUI sooner rather than later though.

So the team decides that the first version of the application will be console based. As we won’t be implementing any central operator service with support for looking up other users in the system, the installed client will be configured to connect directly to another client. Using the metaphor, the team calls this version for the “Direct Line” version. You just lift up the receiver and have another subscriber on the line.

So it is decided that the first iteration will be spent investigating the basics of Ruby and what the options are for implementing simple network connectivity. During that iteration I’ll also look into unit testing support and acceptance testing support.

The second iteration will be spent implementing the “A user can send messages to another user” story. Looking at the estimate for that story we see that it has 5 points. This is relative to the other stories. As all of the stories involve GUI one way or the other, that relative estimate still holds. But we will need to add a user story which adds GUI. As we don’t have enough knowledge about GUI in Ruby, we cannot estimate the new story properly at the moment. We need to add an investigation to get enough info to estimate it properly. We plan to do that investigation in the iteration that follows the implementation of the “Direct Line” console version. In the meantime we give that story an estimate of 3, and expect that estimate to be revised after the investigation.

So the first iterations are planned as follows:

1.Initial Investigations
2.Direct Line – Console Version
3.Ruby GUI Investigations
4.Direct Line – GUI Version

The rest of the stories are deferred to later iterations. I think one could do a more high level release plan that spans further into the future. A plan of that sort would contain a few intermediate releases prior to the final release. I could have done that in this project as well, but for now I’ll just consider this a one release project.

First Shot at a Release Date

The team estimates its velocity to about 5 points per iteration. This project has to share its resources (me) with my family, the swedish summer, some house renovations, and the world cup. So we’re far from the 40-hour work week. The total number of points at the moment are about 45. That would suggest that we need about 9 iterations to complete all stories. This is a rather naive way of doing estimation. We’ve already used up two iterations for investigations, for instance, and there will be more. A really rough, gut feeling, estimate lands at between 10 to 15 iterations.

I expect this estimate to be constantly refined, and I will be in a much better position to estimate after a few iterations. I have deliberately not spent too much time on the overall estimation at this point. Perhaps I should have done it in more detail, but I want to see if, and how, the estimates are self regulated.

The Plan So Far

When I started out I intended to use XPlanner to keep track of my progress. Although I think this may be a great tool, especially for multi-site teams, it doesn’t seem to give me any added value in this particular project. Instead I have switched to plain old pens, notepads, and post-it notes.

This is the project “white board” as it looks at the moment:

At the top are the stories that are in the current iteration. At the bottom to the right are the stories that are scheduled for the next iteration. At the bottom in the middle are the stories in the iteration after that. At the bottom to the left are all stories that are scheduled for later iterations. Pink post-its are investigations. Yellow post-its are user stories.

Time to start looking at Ruby…