Todd's Helpful Hints #1

One college Spring Break I travelled to some popular beach in Florida with an evangelical group known as "Campus Crusade for Christ". I must admit, although I am a Christ follower, my main motivation here was going to the beach for Spring Break on the cheap (like $100 for a week!). On the trip down, I shared a van with a hulking linebacker from Georgetown College. Let's call him 'Jon' (I don't remember his name either). So Jon was a vision of physical power. He was not only large but he was cut to shreds and had a shelf under his pecs where someone could seek shelter in the rain.

During our 10+ hour van ride he noticed a scrawny guy weighing in at a massive 135lbs happily eating a large bag of powdered donuts. Yes, that scrawny guy was me (50 lbs ago) and as I noticed him eyeing my bag of donuts I smiled and said, "Powdered donuts contain muscle building nutrients." He quickly retrieved a notepad and began writing something very important. As he finished, he smiled and showed me what he had written.

Todd' Helpful Hints
---------------------------
1. Powdered donuts contain muscle building nutrients.

Throughout our week long trip, Jon, continued to make note of all my comments that he qualified as "wisdom" that he did not want to forget. I enjoyed the experience but something tells me he never followed any of my "Helpful Hints" and he was simply messing with me.

In that spirit, I want to mention a couple things that I hope are more educated with regards to "Agile Software Development" than my muscle building hints of the past.

To misquote an agile mantra I heard somewhere, "Agile development is more about filling up your Outbox than it is about emptying your Inbox." This means the more stuff we can "Get Done" the better. Even if those things are relatively small.

"Getting Things Done" (GTD) is a methodology or something for becoming a more effective and efficient "Doer". One thing it champions, is a To Do list. Even if you have already done something, write it down and cross it off. To do items should be short as possible because every time you check something off, there is a positive psychological effect to the Doer. Several 'large' tasks tend to stay on your list longer and can potentially have a negative psychological effect to the Doer.

In agile software development, large stories (or worse large tasks) tend to stick around a long time and either get wrapped up toward the end of the sprint, get carried over or get 'split' so that something can be logged as 'Completed' in one sprint and the rest can carry over to the next. If we start off with small stories, we can hopefully get some done early and towards the end of the sprint feel less pressure to 'finish' that large story that is still lingering. Obviously we still want stories that actually mean something but they don't necessarily need to mean 'everything' for a given feature. Perhaps it should be just the first part of a larger feature or the 'Simplest thing that can work' and then next story can be the next 'Simplest thing that can work more'.

Smaller stories also help with source control branching and merging if you are using Git Pull requests. Typically you want Git feature branches to be short lived and closely tied to a user story. If the stories are large, you will either have a feature branch that lasts too long and has merge issues or you will need to create multiple feature branches throughout the work on a particular story. This might be okay and feature branches can be mapped more closely to tasks if necessary but if feels a great deal better to complete a fully tested story as you are merging the feature branch and then subsequently deleting it.

Every team has to find their rhythm and find a comfortable way for defining features/stories so that they can be accomplished in isolation in a reasonable amount of time. My experience is that a larger number of smaller stories causes less stress and flows better than a smaller number of larger stories. One agile book (and there are a bajillion) I don't remember the name of, suggests that a user story should fit on a 3x5 index card with enough information to begin a deeper discussion but if you find you need pages upon pages in a tool like Rally to define a story, it might be too large. Once again, every team must figure out what works best for them.

So that's it! One of Todd's Helpful Hints. Do with it as you choose.

Hopefully it is more useful than, "Powdered donuts provide muscle building nutrients." or some of the other hints that I seem to remember but don't bear repeating.