If you’ve heard of SCRUM, you might be thinking of software development. This is usually where you find people working with this framework.
Well, I’m nothing as such, but I am interested in how to effectively manage my time and my tasks, so I wanted to dive into this and see what this framework can do for me in my daily planning. I’m all into bullet journaling and the benefits of keeping a reliable planning system in place. So I set myself up to learn if and how I could implement certain SCRUM elements to my bullet journaling.
In this article I’m going to briefly explain some elements of SCRUM and how I’ve customized them to fit my bullet journal. Please keep in mind that I’m not a SCRUM expert! But I have found it to be so much fun, and hopefully you will find it useful in your own bullet journaling.
WHAT IS SCRUM?
According to Wikipedia, SCRUM is an “agile framework for developing, delivering and sustaining complex products” and a “lightweight, iterative and incremental framework for managing complex work”. So what on earth does this have to do with an analogue planner system such as the bullet journal? Well, as I found out, quite a lot actually. Let’s compare the two and see how you can implement elements from SCRUM to help us in our bullet journal planning.
Below are a few SCRUM elements that can be beneficial if you want to implement them to your bullet journal system.
SPRINT PLANNING VS. MONTHLY LOG
During the sprint planning, the team gets together and plans out which items on the sprint backlog they are going to be able to complete during the next sprint. To do this, the team needs to estimate the time needed to complete every task. And to do this, the team estimates the relative size of a task. For example, they can use symbols as T-shirt sizes for example, or more commonly they use the Fibonacci sequence to determine the size of a task (1,2,3,5,8,13,21, etc.)
SPRINT VS. WEEKLY LOG
A sprint is usually a time period of two weeks, but it can be everything from one week to a month. There is definitely no rules for us bullet journal users, since I figure that we can apply this as we please.
Most bullet journalists use a monthly calendar, and maybe a weekly as well. And if you think about it, it’s actually quite similar to the idea of the sprint: You plan out your month or week ahead by migrating tasks from the future log, and the sprint lasts for a limited period of time (i.e. 2 weeks).
This time period is carefully planned, so that the tasks at hand aren’t overwhelming the team.
DAILY SCRUM VS. RAPID LOGGING
In the daily rapid logging session, you write out every task, event or note that you need during the day, and you migrate or delete any tasks from the day before.
During the daily SCRUM, the team and the SCRUM master hold a meeting (usually about 15 minutes) and answer these three questions:
- What did I complete yesterday?
- How can I plan to complete my tasks today?
- Is there something preventing me from completing my tasks?
Quite similar to the migration process in the bullet journal, where we migrate tasks from yesterday or delete them.
SPRINT REVIEW/ RETROSPECT VS. MIGRATION USER STORIES VS. BULLETS
The SCRUM framework uses the concept of “user stories” to detect what features they are going to work on during the next sprint. User stories are basically cards where a stake holder (customer) gives the feedback in a specific format:
As a………………………. I want to………………………… so that I can………………………..
These user stories are placed in the backlog by the Product owner, and groomed in a logical way so the next step of the process can be completed during the next sprint. Every user story consists of several “story points”, i.e. tasks that has to be completed in order for the whole user story to be completed.
The team velocity
Something exiting that I’ve learned from SCRUM has to do with the concept of team velocity, i.e. how many user stories/ story points the team will be able to complete during the sprint. This is to avoid burnout and to allow for a healthy flow of tasks during the workflow.
This is something we we bullet journalists could learn from if we might tend to just mindlessly add more tasks to our rapid log. More on that later.
BACKLOG VS. FUTURE LOG
The Backlog is the product owner’s main tool in SCRUM. It is an “icebox” where the user stories are ordered in a logical way. The product owner’s job is to manage the backlog and decide which user stories get to go in there and what need to be thrown away.
This can be compared to a Future Log or the Longtime planning in a bullet journal. Here we put the items that are going to be solved in the future. I don’t know about you, but I keep a future log that also allows for future events that don’t have a specific date yet.
BURN-DOWN CHART
An additional item for the SRUM team to calculate the progress during the sprint is the Burn-down chart. Here all the tasks are listed and checked off in a chart. If you want to try out a burn-down chart, start with small items to get the hang of it. It can be quite overwhelming as well.
THE WORKFLOWS
SCRUM workflow:
Product backlog > Sprint backlog > Sprint / Daily scrum > working increment
Bullet Journal workflow:
Future log > Monthly log > Weekly log > Rapid log
THE BULLET JOURNAL COLLECTIONS
In my opinion, one of the best features of the Bullet Journal system is the idea of collections. These are what makes every bullet journal so unique, If you’re a bullet journal enthusiast like me, you know that the collections can be used for just about anything: recipes, fun oneliners you hear on the bus or a list of books you want to read.
If you want to implement SCRUM elements into your bullet journal, I would suggest that you create a collection called “SCRUM retrospection” and write down your thoughts and reflect on the last sprint.
Time estimation, velocity and planning poker:
One thing that I’ve found to be a useful addition to my bullet journal is the time estimation used in SCRUM. Before every new sprint, the team makes an estimation of how many story points (i.e. tasks) they’re going to be able to complete during the sprint. This is called the team’s velocity.
In the bullet journal, you can add more and more to your rapid logging, which can result in a never ending to-do list. Since some of us tend to be time optimists, we add to the list of tasks if anything new comes up. This can be a trap, if we don’t focus on the tasks we already have.
You can use this idea in your bullet journal. Estimate the time it will take to complete a task when you write it into your future log or monthly log.
How do you do this? You can use relative sizes to code the size of a task. That way you can easily estimate how many tasks you’re able to accomplish that day. This way you don’t migrate more tasks to one day than you can complete.
A popular measure to estimate the size of a task is to T-shirt sizes. My system looks like this:
- S = 15 minutes
- M = 30 minutes
- L = 1 hour
- If a task is estimated to an XL, I usually divide it into smaller tasks.
Comments ()