As almost all developers will know, in a commercial development team, work is handed out in the form of tickets. Each ticket, in my view, represents a single piece of work and no ticket should cross the streams (or subsystems.) ie; the ticket shouldn’t contain requirements for changes to both the code and the database, as this is, in my opinion, two separate tickets that are related to each other (or, the code ticket depends on the database ticket – see the logic?)

Up until recently we’ve been assigning tickets to devs and discussing with them which tickets are next on their list, going by priority, ticket-type etc. Whilst this worked in some cases, in others it didn’t as the priority wasn’t clear enough and developers tended to cherry pick the best tickets first, as opposed to the most important, or they hadn’t written them down or something else came up that was more important and the list was thrown out the window.

A little while ago we decided to move our internal ticket management away from a system which used an in-house support ticket DB and Fogbugz, to the JetBrains YouTrack system (in the interest of clarity Fogbugz still handles incoming email support requests and exception crash reports from our apps – we haven’t moved these – yet!). One of the really nice things about using YouTrack is that we could tag each ticket with a phrase, thereby grouping them into meaningful and descriptive collections, such as “fix in next build” or “needs more info” – exceptionally quick and useful ways of grouping tickets, for us this has been one of the biggest gains after moving to YouTrack.

Through continued use of the tags we started thinking about how we could create an automatic bucket of tickets for developers to pick from. Whilst we wanted to still have some form of choice on ticket selection – let’s face it, there are days when you just want to go through the easy one’s, and there are days when you want something you can get your teeth into – there was a continuous desire to ensure we built software we could eventually release! And from this the “WAT Board” was formed.

Weekly Allocated Tickets, or WATs, are a group of tickets assigned to a developer for a given week. We currently group tickets into three weekly batches. Each week contains a set of tickets that need to be completed. At the end of each week we allocate the third week of tickets to developers – given that the first week will have been completed, the second week will become the first week, the third becomes the second and any tickets that haven’t been completed in the first week rollover  (YouTrack makes us aware of any that have rolled over) – this weekly process is known lovingly as the “WAT Shuffle”.

On a daily basis we check any critical, major or show-stopper tickets that need to be handled and we allocate as necessary. The allocation of the third weeks’ tickets depends on the current load of the developer for the next two weeks and we can move tickets around if necessary.

The WAT Board initially started life as a whiteboard, actually it was a holiday-style whiteboard with a cell for each day. Replacing the months with developer names we could assign five tickets a week to each developer (handy that!) At this point we only gave a small thought to the expected timeframe for each ticket, putting the initial onus on the developer to speak up if there was a problem – this was primarily because the ticket allocation meetings were taking too long. However we realised that we needed to integrate some form of estimation. We also realised that only having six of us up on the board was a problem, so we needed to move to a better system.

So, at this stage we had YouTrack, with tickets being assigned tags to represent the WAT week (WAT1, WAT2 or WAT3 – clever huh!) they were intended for, and there was the whiteboard where your’s truly would copy the list of tickets down – heaven help me if one needed to change – have you ever tried rubbing out a single line of text on a whiteboard without accidentally wiping something else!! After three weeks of doing this it was obvious to all that we need to make something a little better. We also needed to make the process quicker and easier to manage. Something people could look at, interrogate, query – something like a web-app. How about something that could use the YouTrack API?

In the next post I’m going to show you just how easy it is to pull tickets from YouTrack into a radiator using nothing more than a few lines of PHP, a bit of AJAX goodness, some JQuery magic, a sprinkling of CSS and some string.

Then, after that I’ll post about how we use YouTrackSharp, the YouTrack .NET library, to push tickets straight into YouTrack direct from an application.

Oh, and forget the string.

3 thoughts on “Ticket Board: Part One

Leave a Reply