I am using Parallels for some time now for running windows under an iMac. Mostly I use it full screen mode. Whenever we leave fullscreen and get back to OSX, Parallels resizes the desktop. The resulting screen adjustment is really ugly.

Enter Think. Think is a small and beautiful application that stretches a blank (or a selected color) screen below your active application. In effect, the current application is highlighted. It comes along with a semi-transparent control panel. Now, the control panel is available when Parallels is running in the full screen mode. Switching to a Mac application? Use the control panel and select the running application.

If only Think supports using a wallpaper now.

I lurk around the ExtremeProgramming group with an occasional posting or two. Recently there was this thread where there is some discussion about the length of a story. Most people seems to lean towards shorter stories of 1-3 days duration.

The initial wisdom from the XPers seems to point towards longer stories. Both the wiki as well as XPE refers to stories of 1-5 weeks in duration. Even the initial discussions on the XP group favor longer stories. But over a time there was a general move towards shorter one week iterations (XPE2 calls them Weekly Cycle) and a move towards shorter stories.

Contrary to the current trend, longer stories provide better value to an XP project. As a work unit they are easier to handle, buck the half-cone syndrome of cone of uncertainty and make better use of law of averages. Longer stories also have tendency to excite the customer.

Longer stories = Less upfront work to the customer

This must be obvious. The shorter a story the more work is for the customer. They need to write down more story cards, they need to think of finer details about the application and also handle more cards per release and iteration for prioritization.

Longer stories = Less upfront analysis

One of the XP books (I don’t remember which one – though I think it is XP installed) asks the team to practice tearing the cards. That is one of the best advice I have seen. It is really tough to backtrack on something that you have spoken let alone written. But, this is what the teams are asking the customer to do by requesting for shorter stories. Like the design evolves, the application also should evolve. A longer story when discussed during an iteration provides the customers a chance to see the application developed till now and analyze the requirements in the light of what is existing.

Half Cone syndrome of Cone of Uncertainty

A recent post in Steve McConnel's blog is very illuminating. It seems to be the cone of uncertainty for estimates tends towards underestimation in agile projects. I did not read the original article, so I might be totally wrong in the conclusions.

Whatever it may be, my personal experience is that shorter work units are easier to estimate, the estimates are more accurate – but I tend to underestimate the work. You can also do an experiment. Take few story cards and estimate them. Then split the cards into smaller tasks and re-estimate them. In most cases you will find that when split to tasks the combined estimate will be lesser than the story card estimate.

So, by using shorter stories we tend to more create more accurate estimates and at the same time we increase the probability of underestimation. Using longer stories mitigates this risk by letting law of averages work for the team.

Longer stories = More perceived value to the customer

Frankly speaking, I want my customer to be excited when a story is completed. A 1-3 day story can’t excite a customer as much as a 1-3 week story. Where as shorter stories act as a progress report, longer stories provide the extra zing that comes when a customer can accomplish something with the software.

Excuses for using short stories

I enumerate some of the (valid and not so valid) reasons for using short stories.

Easy to estimate

If the team uses yesterday’s weather, estimating a long story is as easy(or tough) as estimating a short story.

Concrete estimates

Estimates are never concrete. The only way we can create concrete estimates to create them post hoc – that is create the estimates after the work is done .

That said, having larger stories does not mean that the estimates are not concrete. Spikes, yesterday’s weather and the power of our minds to use analogies and metaphors allows us to create estimates that are as accurate taken together as when we use shorter stories.

Shorter iterations

This will be a fodder for another post . That said, if the team size is big enough longer stories are still possible with short one-week iterations.

Small teams size

This is one valid reason to avoid stories and go ahead with tasks. My experience is only with teams of medium size and XP4One. I suspect larger stories (for that matter stories them selves) can be avoided for teams that are very small (say 1-4 in size). Any larger XP team can benefit from longer stories.

If you want to discuss this post, I suggest to use ExtremeProgramming group. The blog comments are moderated (though I use akismet I find inappropriate comments once in a while) – and they may appear after some time.

The whole of XP design strategy depends on ‘Do the simplest thing that could possibly work’. It has become a command for XP teams. The c2.com wiki page on DTSTTCPW starts with an excerpt from an interview with WC. The worst part of this excerpt is that it ignores the context in which the question is asked.

According the interview:

And sometimes the programming was almost effortless, as if Smalltalk had been made to write that program. It was amazing. But other times we’d be programming away, and we’d say, “Now, wait a second, what are we working on here?” We’d just get stuck. And if we were stuck more than a minute, I’d stop and say, “Kent, what’s the simplest thing that could possibly work?”

Did you find how it is different from the XP gospel? Here the part is highlighted:

if we were stuck more than a minute

So what WC was saying is that do not stop working because you did not find the best design. Go ahead with whatever simple solution you can find at this time. The act of writing code and concretizing the thoughts will stop us from blocking the progress.

It is worth while to hear these things straight from the horse's mouth.