16 votes

So, yesterday, I turned my ToDo list into a Product Backlog and started my first personal improvement Sprint

Where to post this feels tricky. The terms in my post title -- "Product Backlog" and "Sprint" are very IT-specific terms from a popular business management philosophy (Agile) and methodology (Scrum) for creating software.

However, I am intentionally trying to adopt and adapt these concepts to my own life goals, personal improvement efforts and general day-to-day "get shit done" task lists.

Has anyone else done this? It only just now occurred to me to search the 'Net to see how unusual this idea is, and of course, I'm seeing plenty of evidence that I'm not the first person to think of it.

For the non-IT folk, here's the nutshell version. Large, long-term software development projects get broken down into bite-sized tasks, those pieces get prioritized and best-guesstimated as to each one's difficulty, and then short-term "Sprints" (each generally 1 week to 1 month long) are devoted to completing a selected subset of those tasks.

As an on-going process, the overall project goals and tasklist (the "Product Backlog") get reviewed, re-evaluated and re-prioritized, and past efforts are regularly evaluated for effectiveness, and the lessons learned get incorporated into future planning.

Probably the most significant piece of the Agile philosophy is the iterative process. Never lose sight of the overarching goal, but focus -- hard -- on those bite-sized pieces, always review your own efforts and learn how to improve your process of getting things done, and always be ready to modify all mid-term and long-term goals as the journey unfolds, as new information comes to light.

... And I realize I'm meandering, perhaps, a bit too much into the philosophy of software development ... but I hope it's clear how well this could translate over to personal development, life goals, self-help, stuff like that.

At any rate, that's what I'm doing over the next two weeks ... I'm running my own personal "Life Goals" Sprint, adopting the various tools and terms and ideas built into Agile -- and specifically, the Scrum-style implementation of Agile (which is more philosophy than process). Depending on how it goes, I may well be doing this for a long time to come.

Would love to discuss the idea, get feedback, pros and cons, yada ...

3 comments

  1. [2]
    scrambo
    Link
    How'd you decide when to stop adding to your "Sprint"? Did you assign weights to each task or just kinda eyeball it and think "ehhh, that's enough for now"? I like the idea, I might try that out...

    How'd you decide when to stop adding to your "Sprint"? Did you assign weights to each task or just kinda eyeball it and think "ehhh, that's enough for now"?

    I like the idea, I might try that out to get a couple things crossed off the list that I've been meaning to get to for several months now.

    8 votes
    1. Eric_the_Cerise
      Link Parent
      Part of Scrum is guesstimating how long each task will take, and another part is regularly reviewing and updating those guesstimates. I did a quick-and-dirty first-draft estimate on most of my...

      Part of Scrum is guesstimating how long each task will take, and another part is regularly reviewing and updating those guesstimates.

      I did a quick-and-dirty first-draft estimate on most of my tasklist.

      Additionally, I've been tracking my personal productive activities in Clockify (and, earlier, in Toggl) for years. Using my records there from the past few months, I came up with a preliminary "Velocity" for myself (Scrum-speak for how much a person can get done over the course of one Sprint).

      Assuming I keep doing this, another regular Scrum-step is comparing how well you thought you'd do, vs how well you actually did, and adjusting your plans accordingly.

      2 votes
  2. pocketry
    Link
    I love scrum for working with a team of developers because all the ceremonies make sure there is just enough communication. I think it is generally overkill for very small teams or individuals. To...

    I love scrum for working with a team of developers because all the ceremonies make sure there is just enough communication. I think it is generally overkill for very small teams or individuals.

    To do lists are almost kanban in nature and you would only need to make a few adjustments to turn your to do list into a kanban board. Focus on adhering to the work in progress limits and reducing your cycle time to see improvements.

    Take this with a big grain of salt. All my kanban knowledge is academic and I've never done anything like this personally. If I were to build something myself or work with one other person, I would not choose scrum. I might steal the idea of a retrospective but the focus would be on improving the things I mentioned above.

    3 votes