Since I’m in the middle of flushing out the EBER project, I wanted to explain how I’ve been using the bullet ephemeris for project planning and management.
First, I created a main project page to capture the high level stuff:
Sorry for all the blank space, but it is a personal project after all.
I ended up using vision statements rather than a long narrative paragraph. This means that my vision statement sounds a lot like the kind of things I’d make sigils out of — and don’t think I won’t take advantage of that.
I also very briefly outlined the first two main phases of the project, which are scheduled to take a year. Then I’ll have a month long review / planning period to define and kick off year two. This is important for two reasons: one, the entire first year is focused on information gathering so I won’t know what’s next until I have more information and two, with agile planning I don’t have to know everything in advance.
Consider how lightweight this is. Yes, it takes some thought (and I believe that thought is worthwhile honestly) but the entire purpose of the project takes like half a page. And the high level details for the first year take less than the other half. And this is for a three year project.
The following two pages (left and right) is the start of my backlog, and this is where the bullet journal model really shines. On the left page, I have the epics and stories outlined and numbered. On the right page I create a double column list of short tasks for each story. I do it this way because the inherent limitation of paper is that you can’t insert into a list very easily. Still I’m really enjoying paper for the EBER project planning, so I will keep doing it.
If you wanted to keep your backlog electronically, I’d recommend a hierarchical list with everything in it. That way you could add and insert easily — and no numbering.
And if you like paper, but think more organically, you can create a mindmap version where your epic breaks out into story bubbles and then into task bubbles. Whatever makes sense for your brain (my brain loves bulleted lists, so there you go).
This is a mockup of a backlog / task list page (note comment above about personal project being personal):
Notice I leave a little space in case I want to add stories to an existing epic and that later epics won’t have any stories yet (you plan as you go, not all in advance).
So each story gets a dot (as per the bullet method) and when those stories are added to a sprint (which for me is a month) they get a little arrow. I’ll then jot them down on my month page along with the page of the corresponding task list. When they’re done, they get an ‘X’.
For tasks, I either complete them right off the task list and ‘X’ them out or if they are date based (events, appointments, todos) I schedule them right into my electronic calendar. The scheduled items get a little up arrow (cause the calendar is in the cloud, get it?).
So here’s how the sprint planning process works. Note: this is long when written out, but doesn’t really take that much time (particularly since it’s once a month). If you schedule a little quiet time, you can make it into a very contemplative activity where you review your goals and think about who you are and what you want to accomplish.
Review
-
- I look at last month and see whether I completed the stories I set out to complete.
- If I did, I mark them complete on my backlog (and give myself a pat on the back).
- If I didn’t, I have a decision to make:
- Do I move them forward to next month? If so, I put a forward arrow on the past month and add them to the next month’s page.
- Do I decide to work on them later? I give them a backward arrow effectively putting them back in the backlog.
- Do I decide to scratch the whole idea? No need to continue with something you aren’t finding valuable. I strike it out for the month and on the backlog.
This is useful because if I look at an old month, I can see what happened to the stuff I didn’t do.
I think about what went well and what didn’t and whether I need to adjust course moving forward. I ask questions like “why didn’t I accomplish what I set out to?” “what changed in the last month that affects my project?” “why did I kick ass on this one thing and can I replicate it?”
Preplanning — Update the Backlog
Based on what seems to be the next up priorities, I may take a little time flushing out upcoming epics or stories. That makes planning go smoother. But the further out something is, the less time you spend sorting out the details. Because by the time you get to them, things will have changed anyway. So no need to overthink this.
Planning
- I review the project page to remind myself about my mission, vision, and goals. I make changes as necessary.
- I check my deadline list if I have one, to see what needs to be worked on for upcoming deadlines (that application is due soon, I’d better get my recommendations and write that essay — for example). I add new deadlines as they appear.
- I pick the story or stories for the coming month. Sometimes they come from the backlog and sometimes I make them up based on changing circumstances. Remember, the idea is to complete the entire story in that month. If you can’t then you have to make the story smaller (or even, in a pinch, have a part one and part two). If you decide to do more than one story, they can be from different epics (which is how you work on more than one thing at a time).
- I make sure the stories have their tasks listed and add / update / strike out tasks as necessary.
- I write the stories on the monthly planner page and note the task page (you can also rewrite the tasks for your month, your choice).
- I schedule the tasks that have a date and/or time.One useful thing to remember is that you don’t have to keep some pristine single source for all of this. If you have stuff to do, you can write it straight into the month page and skip the backlog. The backlog is a holding pen for stuff you have yet to do, so you can dump all your ideas for meeting your project goals. But stuff changes as you go so you want to stay flexible — which can mean messy. Just make sure your stories includes a reason (why you need to do the thing) that aligns with your vision and values. That’s how you keep your project in focus.
Important — any part of your project is fair game for changing. If you decide mid-way through that your goal is wrong, a new opportunity presents itself, or a huge risk appears that you didn’t anticipate, you need to react to that. Anything is up for changing, even the project itself:
- Maybe all your efforts and magic means that you meet your goal suddenly and way earlier than you planned (yay!!!). So call it a success and move on.
- Maybe something big and bad arose that you have to put all your effort toward (boo!!!). So defer your goal until later and start on the new thing.
- Maybe you complete the first epic of your goal and think “fuck this ring nonsense, I’m going to retire to Tahiti and start hospice for the rehabilitation of troubled Gollums” (change!!!). So you ax the project, call it a learning experience and reset your sights on the thing you REALLY want.
This is also, bluntly, what separates agile from other project planners (some printed out in very lovely hardbound books for quite a lot of money). Having goals is good and so is planning to get those goals done. But life is messy, change is constant, and the world is filled with uncertainty. Pretending that isn’t the case is how you end up with stiff, complicated plans that you never look at again, being able to only have near-term goals without a longer-term vision, or — even worse — achieving a goal without ever stopping to realize it’s the wrong goal.
