Promising and committing

Commit messages suck. If you don’t trust me, enter “svn/git/hg log” in your command line and see yourself. I’m personally tired of seeing endless “Fixes”, “Tests”, etc. in TeamCity build history. Nonetheless, when Mercurial asks me what the hell I was doing for the last hour before it agrees to share my changes with the team, I stare at the text field for couple seconds and, honestly, sometimes end with another “Fixes” poo.

Commit messages should generally follow the same guidelines as status reports at your daily scrum. They must be short, clear and (sometimes) inspiring. This is often not the case because of the huge stream of bugs, change requests, code smells, etc. pumping into your brain at incredible pace.

Experienced developers know that microcommits work best: a small change gets meaningful description easier. The problem is that controlling yourself is hard: when you start hacking your code you normally have a very broad ‘make this stuff even better’ vision in your head. And only in half an hour or more the system asks you to give a name tag to your actions.

Wouldn’t it be better if you could give your commit message before making change? You open up your Twitter favoride IDE and see a nice ‘What’s happening:’ ‘What are you doing:’ text field. You browse your issue tracker, take a look at the scrum board, reflect for a minute and write ‘Implement masterpiece wizard in Photoshop’. And this text is up there at the top of your code editor always reminding of what you’re doing. Now, whenever you switch to something else, you finish this thing first, commit and then change the message to start a new thing.

LOD in Scrum Product Backlogs

We have recently started using Scrum in our teams and one of the things that immediately changed was the way we store features. We used to keep them along with issues in the bug tracking software (YouTrack in our case), but this doesn’t work well with Scrum as we need to arbitrarily order them (three priorities to sort by are just not enough).

So we switched to Checkvist (I should dedicate a separate post for this awesome piece of software) which is basically a very usable outliniing tool.

First we struggled with lack of structure in simple hierarchy of text labels: how to plan sprints and versions, how to group issues by user scanerios, etc.

Over the course of several weeks I came up with the following system which you might find helpful. It is based on LOD (Level-Of-Detail) approach used in computer games to determine how much details to put into rendering objects depending on distance to them: the monster you’re standing next to is very beautifully rendered with hi-res textures, bump-mapping and lots of vertices in the mesh. Trees and a church on the horizon are rendered with little details and smaller texture so you don’t waste CPU cycles (if you’re killed by the monster, you won’t reach the church, so why spend resources on it now).

The backlog is divided into five sections: INCOMING, SCENARIOS, DEFINED, PLANNED FOR SPRINT and DONE.

All incoming requests are put at the end of the INCOMING section. These are very basic requests from team members and end-users. If the request was submitted through the issue tracker, I attach a link to the request. I use tags in this area to mark requests with areas of interest: #performance, #overview, #code-intelligence, etc.

The next section is where I create end user scenarios to implement: these are combinations of improvements which enable users to more cool stuff in a specific area. In these stories I group requests from the INCOMING section and add missing pieces. An example of story would be: “Support AppEngine” or “Taggable work items”.

The next section, DEFINED, is where I get very specific about how to implement particular story: all items which are in DEFINED section have good HOWTO-DEMO descriptions. This section is where team members should look quite often to analyze if something is missing or should be done differently. This is where ideas turn into actions. This is the place where we take items from for planning, so items in this section are ordered by priority.

The rest two sections: PLANNED FOR SPRINT and DONE are easy: after planning meeting all items planned for the upcoming sprint are moved from DEFINED to PLANNED FOR SPRINT. All items which are completed as part of the sprint come back to DEFINED.

Pretty simple and easy to understand. So far works very well for us.