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.