Ian: “Looks like the door won’t be photo-ready tonight.”

Me: “Neither will my crate or the window. That’s why I was lamenting that we didn’t have any painter’s tape – because I could have got painting it today.”

Ian: “So none of our projects are photo-ready? Then as far as the Internet’s concerned, we did NOTHING with our weekend.”

So true.

So You can Get Shit Done…

So, if you want to try managing your own tasks (household or otherwise) with Agile/Scrum, here’s what you’ll need:

• index cards to write your tasks on
• A sharpie or felt pen for writing tasks – it’s easier for your brain to pick up what needs doing if you can read the card from a bit of a distance
• Some kind of board. My favourite set-up is a magnetic white board, since you’ll want to move your cards around a lot to prioritize them or move them into the current sprint. Unsticking and resticking tape or sticky putty is a pain while moving a card and a magnet is pretty easy.

We’re currently using taped cards on glass. One day we’ll experiment with putting something magnetic behind the glass (when that card comes up in the backlog), but for now tape is working for us. Also, I haven’t tried it, but you could make yourself a tasteful pin-board or corkboard and aside from not being able to write on them, they’d have the advantage of easily moving your cards around.

1. Take your “to-do” lists and write everything down on cards. One item per card. If an item can’t be done in a day or two, you might have to break it down into smaller tasks.
   I don’t tend to put small, recurring items like grocery shopping or cleaning the kitchen on cards. My aim is to figure out how long various projects will take us and to make sure time-sensitive tasks don’t slip through the cracks. So I pretty much only put it in if it’s project level or occurs once or twice a year. However, if your goal is to involve your kids, maybe you’ll want to write down the tasks that are small enough for them to pick up. There is a scrum tradition of writing your cards in “user stories”, which have a format like “As a [role of person who will use the feature] I can [action that the feature should facilitate] so that [benefit to the user].” Which is fantastic for application development as an antidote to traditional specifications. Typically, specifications try to capture the details of implementation, but then often obscure what it is the user needs to actually get out of the feature, while one of the great advantages to scrum is how it moves us towards trusting the implementation to the developer. I agree with user stories in development, but I find them difficult to write for household tasks. So I write them whenever I can, but I’m not diligent about it.For example, “As a family member, I can start the Explorer reliably so I won’t be late when going anywhere” captures that the primary objective of the task is a reliably starting vehicle. I could have written, “replace the starter” – but it’s hard for the card-writer to know 100% that the issue IS actually the starter. Instead, it’s a good idea to just write the needed value and trust the implementer to find the right way to achieve that value. However, when a task is cosmetic, for example, I find it hard to articulate the value that prettying up the place has.
2. The stack of cards you have now is called your backlog. Go through those cards with your team (spouse, family, roommates, whatever) and start assigning points values to each card.
   Points are an arbitrary unit – the points values that your team assigns to a taks wouldn’t necessarily match what any other team assigned. They should come from the gut and capture basically whether the task is simple or complicated. In order to keep it non-specific and gut-level, we use fibonacci numbers- so that as a task gets more and more difficult, you concern yourself less with precisely how difficult.The key here is to not overthink it. Start with 1, 2 and 3 – where 1 = “pretty simple. Just needs someone to set aside a portion of their day and do it”, 2 = “a little bit complicated. might take some planning” and 3 = “pretty complicated. probably won’t feel like doing anything else with my weekend. may contain some unknowns.” If it’s more complicated than a 3, the next number is 5. If it’s more complicated than a 5, the next number is 8. And honestly, if you’re estimating things at an 8, you should stop and break it down into smaller tasks. You should probably break 5s down too. And remember that as you get more experience with estimating, your team will have a better feel for what those numbers mean to your teamand it will probably evolve from this starting point.
   

   I keep backlog items in a vintage portfolio case and then file finished cards in little file-folders in a basket near my scrum board.

3. Now that you have difficulties for all your tasks estimated. Go through and start prioritizing them.
   If I have a big stack, I start by dividing them into two piles. “Must be done in the near future” vs. “can wait for the right time”. Then I take the near future pile and I pick an arbitrary time frame like “eight weeks” and divide into two piles again; “next eight weeks” vs “can wait a little bit”. When I have a manageable stack, then I’ll just sort them according to what provides the highest value for the household. Remember that your backlog will be fluid. Circumstances will change and you will re-prioritize. Every time you think of something that you need to do, you’ll write a card and find where it belongs in the stack. Just make sure that the things right at the top belong at the top and the rests will settle into order as you work your way through your sprints.
4. Take the top of your pile and start planning your first sprint
   Looking at the top few cards, ask your team if you can get them done in the next week, keep pulling in cards until the answer is no. The total value of the points estimates on the cards you think you can do is your Velocity Estimate for the coming sprint. Don’t forget to name your sprint – that’s the most fun part. We like to name our sprints alphabetically, so we can always tell what got done in what order. And then we pick a theme such as Childhood TV shows or 80s Pop Bands.
5. Put your sprint on your board
   There are many different flavours of scrum board layouts, so you should feel free to tweak any design until it suits the needs of your team (this falls under the heading of reviewing and tweaking your process to improve your performance on future sprints). However, because it’s not software development and because we are our own client, we find most of the layout superfluous and we use a very stripped down scrum board. Many scrum boards will have columns for each phase that a story can move through from the ‘Backlog’ to the ‘Sprint’ to ‘In Progress’ then ‘Needs Demo’ then ‘Done’. Because we always know what the other person is working on and there’s no need for us to demo our handiwork to the client (Ian and I typically show off our work to each other as soon as we’re done. If we’re both agreed that it’s done, then it’s done), we have reduced it to two columns: Backlog and Sprint. If it’s planned for this week, it goes in the sprint column. Then we put the top few cards from the backlog into the backlog column just so we can see what’s coming up and so that if we have a stellar week and start pulling tasks from the backlog we don’t have to go digging in order to find the next thing that needs doing.
6. Start Sprinting
   We start our sprints every Saturday morning. As we’re making the coffee, we’ll find a point to get together by the scrum board, name our sprint and pull in the cards we intend to finish in that sprint. From there, we each pick what we’ll be working on and plan our day.Traditional scrum has a daily stand-up; a five minute meeting at the board where each team member states what they accomplished in the previous day and what they’ll accomplish in the coming day. This is fantastic with coworkers, but seems silly for spouses whose daily communications follow that pattern anyway. If I got up in the morning and I didn’t know what Ian had accomplished yesterday, that would be really weird for me. But if your family tends to be solo-workers who don’t check in on each other throughout the day, a formalized daily stand-up might be a good idea in order to keep everyone on track and communicating.As we finish cards, we pull them off the board, write the sprint name on them so we’ll know when they got done and tuck them into a little folder. The following Saturday we can look at the board to make sure everything got done, or we can pull cards out of the folder to see how we did. That’s the point when we’ll give ourselves feedback on how the last sprint went and bring up any ideas for how to refine our process for the coming sprint. Again, traditional scrum has a prescribed process for sprint retrospectives, which you can look up if you like because it can be really useful if you feel like you’re not really improving your process or if you feel like there are some big issues around how things get done and those issues aren’t being addressed.

If you need clarification as you get started, you can find a lot of articles on the internet about scrum processes – but since this is for household management, not application development (you shouldn’t need testing and QA, demos or multiple sign-offs), you can keep your process a lot simpler than the prescribed processes.

Lastly, keep it fun. Although this process came from software development workplaces – you’re using it on your discretionary time and where your loved ones participate. It’s not supposed to be work, it’s supposed to be tool to help your household get the most value out of their time. If you’re not happy with the results, then the items that are getting done aren’t providing much value, are they? And remember that the work you put into getting things done shouldn’t fill up all your discretionary time, or if it does, you better be working in stories that cover all the household value you need – including family outings and down-time for yourself.

A new weekend is upon us; time to begin the next cycle of Getting Shit Done.

Remember last spring when I bought some vintage windows and said that I was going to be done that project so fast that I’d just tell you what I was going to do with them when I was done? Well, it was actually pretty fast, but then I never came back and said what I’d done with them. So, now you know: what I did was paint the back of the glass so I could hang them up and use them as white-boards.

They are now hanging in my back room, with one of them serving as a plain old white-board for lists, etc and one serving as a scrum board to help me organize my life.

A scrum board is a tool for managing agile software development. We use them at work, and since bringing the idea home for managing the household, I’ve had a number of people ask me how I make it translate to household management, so I thought I’d just post it here for reference.

There would be a lot to cover if I were going to try explaining scrum fully, because it’s an in-depth software development methodology with decades of books written about it. There are experts and consultants to help you learn and implement it and certifications and affiliations you can acquire to qualify yourself in it. But those things are about managing tasks with many stakeholders (developers, the developers’ employer, the client and the end-user) in development situations where a feature’s needs are often poorly understood at the outset of the project. For managing your household, you can strip scrum down quite a bit.

The basics of scrum that you should adhere to are:

1. You work in regular segments of time (like a week or two weeks), called sprints.
2. Tasks are organized to be as granular and discrete as possible. You estimate each task’s difficulty in abstract “points” (not time or anything measurable), then you put them in priority order based on which task provides the most value. Using the points estimates for context in how complex tasks are you then decide how much of the list you can get done in your next sprint.
3. You wrap up each sprint with an honest look back on the last sprint in order to strategize how to do better in the next sprint.

The whole point behind it is the creation of that feedback loop. As long as you are honest with the feedback, each iteration through that loop should allow you to perform better.

The main benefits are:

- because you prioritize your tasks based on what delivers the most value it becomes more difficult to procrastinate or avoid tasks. So if fixing the toilet is at the top of the priority list but you find yourself saying “well I can’t do that until I’ve cleaned out the fridge”, you have to honestly ask yourself, “why didn’t I write a card for cleaning the fridge then? Or if I did, why isn’t it higher on the list than fixing the toilet”.

- because your tasks are granular and prioritized, you don’t get bogged down in hinging one task on another task which hinges on another task. For example, we’re totally the kind of people who say things like, “the kids’ rooms need cold-air returns in them because the air flow isn’t enough to keep them warm. But if we’re going to run some new ducting up there and we’re ripping apart the walls anyway, then we should run it next to this wall that we wanted to change the layout of, which means we should probably plan the built-in bookshelves we wanted in that wall”. But when you look at the priorities, “cold air returns” provides way more value than “move this wall”, so really, given the effort involved in the wall moving against the value it will provide, you have to admit that you probably won’t get to wall-moving in the next couple of years and cold air returns are way higher priority than that. Turns out they’re high enough priority that they should be undertaken even if you can’t save effort by combining two projects.

- if you’re a team (or a couple), it encourages you to be cross-functional – especially if the tasks are unequally weighted towards one person’s strengths. Because if all the things at the top of the list are not your strength but the person or people who are strong in them are already doing tasks, then you’re just going to have to pick one up and figure it out. Again, it just comes down to priorities. You could skip your way down to something that you like doing better, but it wouldn’t be honest or fair and the board with the list of cards in priority order makes that obvious.

Primarily we’ve found it helps a lot with prioritizing. We have such a list of tasks (SUCH a list) that it had become hard for us to track. High priority things would get forgotten and seasonal tasks wouldn’t get done before the end of the season and whenever we had a moment to work on things, we couldn’t remember what our next priority was and we would totally just fritter time away non-valuable tasks. This process lets us easily break things down into sprint-sized phases so that we only have to focus on a few things at a time, it makes it easy to move from one task to the next without having to stop and debate what the next task should be, it lets us plan for big projects without spreading ourselves too thin and it keeps us from wasting time on make-work projects that don’t provide much benefit.

If you decide to try scrum, don’t make the mistake of pushing yourself super-hard and needlessly upping your estimates of what you can get done. Most of us feel like the point of measuring is to keep you in high-performance mode – but the point of scrum is to aim for a sustainable and predictable working pace. We know that when we’re really pushing ourselves, we can do almost twice as many points in a week, but we can’t sustain that pace. If we aim for what we can sustain, then it’s easy to plan our upcoming work to make sure that time-sensitive tasks end up in the right sprints.

If you’re interested in how big a project we’ve managed to make it through using this system – we pretty much got through the whole sewer excavation, replacement and stair building using scrum. Ian did most of that work, so his would really be the final word on whether it was helpful, but I found that it kept us on track whenever we started to overthink a task by working in too many factors – we’d come back to what was on the card and say to ourselves, “it just says build the stairs. Let’s not overthink what the wall next to the stairs is going to look like or how it’s going to fit together. Those questions can be handled when we pick up that card in the future.” It also helped us estimate how long the whole project was going to take. We started it when Christmas was only eight weeks away – and if we could only work on it for our weekends, it was going to be pretty hard to predict how liveable our house would be for Christmas. But, knowing that we do about 3 to 4 points worth of effort on weekends, and having already put points values on each individual tasks we were able to keep tabs on what was likely to be done when.

Aside: while it was completely a fortuitous accident that the old catch on the window perfectly holds one of my whiteboard markers, it should be easy enough to reproduce. The catch seems like the standard size that I’m used to seeing on all the old windows (in my city anyway). And the marker is a Quartet – the kind where the lid is fluted in a slightly Calla Lily shape – which is integral to the way it fits in the catch.

In my next post, I’ll go into more detail on the actual steps that we follow in our Household Scrum process.

Hannah: Can I get a cat and when I move away from home, I’ll take it with me?

Me: Well, we won’t be getting a cat for a while, so we’d have to discuss that when you’re much older. But you can plan to have as many pets as you like if you want to buy them for yourself when you move out on your own.

Hannah: If you don’t want a pet in your house, then I will just have to move away from your house right away.

Me: Oh?

Hannah: But I will drive to your house to see you when I miss you …If I think about you.

…

Damn right I didn’t have anything to say to that.