psBacklog and psTimebox

When a team undertakes a scrum approach to their work, they define a timebox. They then use yesterday’s weather to define velocity and determine what they can accomplish within the timebox. For the personal scrum, we will also define a timebox. However, we are going to use yesterday’s weather as well as last weeks and last months (when we have them) to define velocity and anti-velocity. Remember, Velocity is going to represent the amount of time we are able to spend on our project tasks and Anti-Velocity is going to represent the amount of time we spend on other things – our personal tasks.

Though I am sure I can stretch the analogy sufficiently, I can not think of what would easily be analogous to the release within a regular scrum. Therefore, let’s start with defining a sprint timebox and a backlog for it. My recommendation is that the timebox should be a week: Monday through Friday (add Saturday and Sunday, if you really want, but I chose to be completely anti-velocity on those days!). The backlog should be that set of tasks you need to complete during the week. The set would include those stories and tasks committed to for your project sprint perhaps, but also those lunch dates, dentist appointments, HR meetings, and so on. Basically, the personal scrum backlog (psBacklog) should include everything you put on your calendar, all your committed tasks, and sufficient time to complete other work life activities. Each tasks should be estimated in ideal time – assume you will start it and not allow yourself to be interrupted until you are done.

Here is my psBacklog for last week:

Those items marked with an * indicate that they are time-tied to the calendar. The travel estimate to CA (marked **) is 4 ideal hours because of the time change – I am scheduled to land by noon – 4 hours out of my work day. The items marked (daily) are repeated every day, but don’t necessarily get tied to a specific time.

Now, though you will notice that these are all work related, they are not all work. Let’s take the third one as an example. Due to the somewhat dehumanizing search and seizure within my toiletries bag, I needed to run out to the drugstore before they closed on the first day of my travels. I had many choices of where to go and when to go, as long as it was sometime that day. Thus, this becomes a required task, one of variable length (based upon where I end up deciding to go), and one that can be moved for the convenience of other tasks. Ultimately, I took care of it after dinner, allowing it not to conflict with other tasks with less flexibility.

The estimates are of equal interest. For example, the first task. I estimated it as a 4 hour task since it would only eat into my west coast schedule by 4 hours. The 4 ideal hours gives me the ability to create an idealized schedule for my personal scrum for the day. The reality was the flights and the rental car check out were slow and so I did not get to the office until 2pm. Since I had started out that morning at 4:30am so that I could allow the search and seizure not to create excessive anxiety on my travails, the elapsed time for the trip was really 11 ½ hours. Since I am neither paid hourly nor bill/charge for travel time, this was immaterial, but forced two things: 1) my plan on running to the drug store during lunch was changed as the lunch hour was spend on the runway and forced a rescheduling event to occur. 2) My 1pm meeting slot (task 2) was moved to 3pm.

Fortunately, the travel delays did not necessitate shifting any Monday tasks until Tuesday. I was able to accommodate most of the unscheduled but required daily tasks (the last three in the backlog) on the airplane and in the airports (free wireless at the airport), so the compression of the schedule at the end of the day was less problematic.