You should plan your move with scrum.
A member of my scrum training cohort recently shared a blog post about bringing agile principles into the workplace outside of tech. This inspired me to share how I’m bringing agile principles outside of the workplace when planning my household move. Shoutout to Will for inspiring me to write about something agile related.
Why you should plan your move with scrum.
Scrum breaks down seemingly impossible work into smaller, achievable parts
This framework gives you the freedom to complete your work on your own time, provided you are contributing to the success of your team
It removes the tension from emotionally charged topics
How? Start with a backlog.
You’re going to need a backlog.. We decided to think of the contents of each room and we wrote out a checklist of what needed to be packed. The items in the backlog list an acronym for the part of the house, along with a brief task description. We call each task a “card”.
Living Room (LR): pack up board games and records
The backlog has to be visible. For best results, make this a document all of your teammates can view. You can go analog by using post it-notes and a wall, or you can digitize this. For our purposes, we created a spreadsheet using Numbers.
Work backwards. It’s helpful to think through all of the items that need to remain unpacked until the week or days leading up to Move-In Day. We actually created that as separate columns, so we have a general column for things that can be packed at any point, and another column for things that cannot be packed until the week or days leading up to the move.
Make a Kanban board. Next to our task cards we created a simple Kanban board so we could track To Do, In Progress, and Done.
Lastly, we decided to house notes on what items were going to end up on the truck versus in our car.
Choose the duration of your iteration.
Work expands to the time allotted, and the only surefire way to get around this is to time box. We started planning out our move about two months before move-in day so we figured out we had 8 weeks to pack and clean the house. From there we decided we would work through items in our backlog in one week sprints.
Since we knew we were going to hold our version of daily standup in the mornings before work, we decided to consider Sunday the first day of the sprint. More on that later.
Using the 5 scrum ceremonies as our guide, we had regular discussions about our plan, work strategy, and progress.
Use the 5 ceremonies.
Scrum suggests holding five different recurring meetings but for lots of reasons these are called events or ceremonies, instead of “meetings”.
In my workplace, these are strictly observed as five distinctly different discussions, and their cadence is nearly set in stone. But since it’s just Keith and me around here, we often combine these discussions or skip if we don’t feel it’s needed.
Refinement
Sprint Planning
Daily Standup
Sprint Review
Retrospective
This would be a very ugly sprint cycle in the real world, but here’s how we ended up doing things. (Yeah the graphic is kinda ugly, too. It’s fine. #MinimumViableProduct)
Refinement and Sprint Planning
These two events are very different things, but for our purposes, we combine these discussions and do refining + planning at the same time, on the first day of the sprint. These are the longest and most involved events in scrum, so we chose Sunday (non-work day for us) as the first day of the sprint.
Clarify tasks and expectations
Estimate and order
Assign items from the backlog to a sprint
Set a sprint goal
Clarify tasks.
We always have some sort of refinement discussion before sprint planning, so we can clarify on the backlog. The main goal is to make sure we understand the expectation of every task, especially the ones that are coming next. Consider this card:
LR: pack entertainment center
When I saw this living room card I started to have questions about the best way to pack the TV. In this case, the TV is on top of the entertainment center, but it’s larger and bulkier than any of the other electronics. This makes me wonder how we plan to move it. So I asked.
Me: Hey I see this item in our backlog but I don’t know the best way to pack the TV. I don’t think we have the box it came in so should we plan on moving this ourselves in our car? If so, should we write that task on a separate card?
When you refine a backlog or work through a project you will always find more work. Maybe something slipped through the cracks or maybe some cards are no longer needed. This is one of the reasons why refinement is so helpful– it holds space for a dedicated conversation about new or missing work.
Returning to the example above, the entertainment center card really felt like two tasks so we created a second one for the TV.
LR: pack entertainment center
LR: pack TV
Estimate.
It can be helpful to estimate and prioritize work, especially when working towards specific dates. Estimation is very useful, but also highly subjective, so we spent some time deciding on a system that made sense to us. Based on the Fibonacci system, we assigned number values to indicate the complexity of each card. Consider the cards:
LR: pack entertainment center (1)
LR: pack TV (2)
1s and 2s usually indicate that the items are not fragile, easily packable, and do not take up a lot of space. 3s and 5s are reserved for tasks that are more complex and time consuming.
Since I know all of the contents in the entertainment center can fit in one bin, and that none of the items are fragile, I can estimate that this task won’t take me very long. I’ve assigned it a 1.
When considering the TV, I know that’s a bit more involved. It’s heavy and will have to be wrapped since we don’t have a box for it. I also want to move this in my car rather than on a moving truck, so that creates a special case for how it’s handled on Move-In Day. It’s a 2.
If you’re new to the estimation process, check out this article which outlines the variables you may want to consider.
Estimation and Order When Planning
When it comes to estimating how long it will take a team to complete work, there’s a pretty big debate in the real scrum world about using a points system versus tracking hours (estimated hours and actual hours). One reason for the contention is that the entire goal of a scrum master is to build predictable, fast delivering teams, and there’s more than one way to do that.
Tracking the amount of work completed in each sprint gives you a quantitative metric you can use to predict the amount of work a team is capable of completing in each sprint. Scrum calls this lagging metric velocity.
This is helpful when thinking of the moving project because we want to know about how many points we should complete in a day, sprint, two sprints, etc. towards reaching project completion.
We visit these metrics during Sprint Planning, by counting the number of points we completed in a sprint and we use that data, along with the number of remaining points on the board, to inform how many points we need to bring into the next sprint.
If a card took us longer than anticipated, we reflect on why we thought we underestimated its level of effort during the retrospective, and we take that feedback into account in future estimation exercises. I’ll share an example during the retrospective section later on.
Daily Standup
Keith and I have a daily “sit down” over coffee. During this event we pull up the backlog and share what we accomplished the day before. We also talk through our plan for the day and discuss any blockers or dependencies.
Keith: Yesterday I removed the decorations from the guest bedroom wall, and I disassembled the headboard. Today I plan on removing the nails from the empty walls and packing up the books in the dining room.
As Keith is talking, he’s moving the tasks around on the spreadsheet within the three different categories on the Kanban board: To Do, Doing, and Done. He’s displaying this so I can see it in real time.
Keith: Before I pack up the books in the dining room I would like to have the books you have around the house in the same pile. We also need more packing tape.
Keith has just shared a dependency: he needs me to find all the books I’m currently reading and place them near the dining room so he can box them up. He’s also shared a blocker: He cannot complete this task until we find (or purchase) packing tape.
Our daily sit downs last about 15 minutes, and we have this conversation right before work. This allows us to factor in our moving tasks when thinking of our work day.
Sprint Review
Talk through the outcome of the sprint
What got done
What didn’t get done, and why
Near the end of this sprint we hold our Sprint Review and Retrospective discussions.
For the Sprint Review, we pull up our spreadsheet and look at the Kanban board. Most often we have a lot in the Done category, and maybe a couple of low point items In Progress.
RE: Done. In the tech world, this is a time to internally demo finished tasks to the team.. For our purposes, we talk through how we accomplished the task and where the packed box currently lives.
Me: I changed the sheets on our bed for the last time and took all the linens from the house downstairs. The bigger blankets and duvet covers are in boxes, but sheets and tablecloths are on the table so they can be used for packing fragile items.
RE: In Progress. If there are items in progress during our Sprint Review, we discuss whether or not they will get done before Planning for the next sprint, or whether they should carry over.
Me: I meant to pack up the sewing machine, but I needed to hem a pair of pants before the wedding we’re attending this weekend. If you can try on the pants and make sure they fit, I can box up the sewing machine tonight.
By the end of the Sprint Review we know exactly what we completed, and what’s left before we can close out the sprint. And since we have estimated all our cards, we have a number that can help us inform the amount of work we want to take in next.
Retrospective
Do an activity
Reflect on sprint health
What was good
What wasn’t good
What should we try next
Kudos / celebrations
At work, the retrospective is my favorite ceremony. It’s advised to hold this at the very end of the sprint so it can close the door on the iteration. The format I use at work is listed in the bullets above, but for the move, it’s easiest to jump right into the reflection.
Me: I really liked how we assigned cards to either you or me, but sometimes I had to pull you away from your work to help me play tetris with the box contents or help me decide where to put the box after I was done. Can we try doing each card together?
Keith: I like dividing and conquering because we’re covering more ground in a shorter amount of time. It’s more efficient. How about we meet in the middle and take on the larger cards with higher point values together? I can also help get you started on some of your cards before I work on mine.
Voila- we have a retrospective action item: Share tasks on larger cards rather than divide them up. We can try this for a couple of days and adopt it if it works, ditch it if it doesn’t.
At the very end of the retrospective, we close out with kudos and celebrations. Cheesy as it may seem, DO NOT SKIP THIS PART. It’s a great way to pause and verbally communicate appreciation to one another. It also energizes the team for the next sprint!
End Scene
I know you’re thinking NERD ALERT and that’s fair. But maybe this helped show you how the scrum framework can be modified to help you work through large projects in and outside of the workplace. It’s certainly helped me exercise my scrum master training in a different way, and it’s also allowed me to teach Keith a fair bit about scrum.
It has given us common language and ritual as we juggle full time jobs in the middle of a move. And although moving tasks have taken chunks out of our free time, we recently took a week-long vacation and we have been able to keep our social plans on the calendar throughout this process.
P. S. If you’re also a nerd and want our Numbers template, reach out :)
