Scrum has two types of backlogs. Product backlog is basically the whole plan for doing the thing you are trying to accomplish. Product backlog develops constantly as more is learnt and stuff is added or removed or finished, but it's still functionally sort of the same as a project plan would be for a traditional project: what needs to happen and how much work might it be in total etc. In Scrum, the product owner is the sole authority on the product backlog and they are responsible for keeping it up to date.

Sprint backlog is the second type of backlog. The development team (meaning basically the people who will actually do the work. There will be a post about the different Scrum roles later, don't worry) owns the sprint backlog and it represents what the team sees as the most important and feasible collection of things to work on during this sprint. The things are lifted out of the product backlog.

How do these work with scrumlife?

Exactly the same as they would in a normal Scrum project, actually. This might turn out to be a shorter post than I anticipated...

However, the real question is what gets put to the backlog. I'm in a couple of teams. Just one of those teams is a scrumlife team. Scrum is funny in that it openly says that not everything should be done by using Scrum. Scrum is great at exploring things and handling complex situations, but there are a lot of areas in life that are not at all complex. Everyone at my house loves this one gnocchi dish. I have the recipe and the shopping list ready for it, so I don't need to solve this problem anymore. I just do it.

On the other hand, finding a bunch of similar recipes that everyone enthusiastically eats could be a good epic for my product backlog. Finding those will take research, delivering (some hot meals) and listening for stakeholder feedback. So maybe each new recipe comes in as a PBI?

(Sidenote: talking about recipes as PBIs, or Product Backlog Items, is exactly the type of silly thing that makes these projects fun.)

Anyways, things I want to explore in some way go to the product backlog. Either the thing itself is new or it's related to something new. I know how to write a blog post for example, but all scrumlife posts still get put to the backlog. I want to prioritize them separately, track how they do and keep tabs in general how the blog develops over time. If I knew all this in advance I could just write all the posts now and schedule them perfectly but as I don't yet have any idea where this whole process is taking me, I have to take it one step at a time.

Which means putting these things on the product backlog and then picking them for the sprint backlog when it's time for them to actually happen. Building a sprint backlog happens in sprint planning. Guided by the sprint goal, the relevant items are picked from the product backlog to be worked on during the following sprint. It's relevant to notice that the sprint backlog is even more fluid than the product backlog. It's not a promise that everything on it will be done or that nothing else will be done during that sprint. If reaching the sprint goal requires it, the sprint backlog can in principle be completely changed during a sprint.

I have a separate blog post up on sprint planning and sprint goals. Go read that if none of this makes sense 😅

Now, let's show how I work with these backlogs in practice. They both live in OmniFocus. I have a project for scrumlife, that includes everything that has anything to do with the project.

All items have an actual thing that should be somehow delivered: blog is posted, meal is served or something is measured. Sometimes delivering something just means that I read something and now have the knowledge, so there's some GTO flavour thrown in there also. I want all the items to be actionable, meaning that they can actually be done. "Have a great marketing strategy" for example would not be something I can just do. I have to research it a bit first, so I fill in research as a separate item on the product backlog.

When I pick an item to be worked on I "flag" them. I have built a separate perspective in OmniFocus which picks up all the things that are in the backlog and have been flagged. This way I have quick way to see and manage all the PBIs and I can also use widgets and shortcuts to show and find these.

You could do this in Trello or on a physical wall with post-it notes as well. I just want to keep the amount of systems I use to a minimum so into OmniFocus these go too.

And that's about it! It will be interesting to see if I can keep the "normal" to-do side and the product backlog separate or if it will turn out to be confusing.

We'll see!