Applying Scrum To Our Own Personal Development.
This is based on a self-improvement experiment I tried a while back but struggled with. I now know that I didn’t break my work into small enough chunks–That, and I lacked discipline. So I want to try it again, but I want to invite any readers to try this themselves. C’mon! It’ll be fun!
We’ll be creating our own personal backlogs that will consist of a list of traits each of us wants to improve on in our own lives. These “stories” will be driven by the need to improve in our personal development. You might have some personality traits you want to work on. Maybe you are looking for spiritual growth–or just getting it together. You might want to get back to playing a musical instrument or tap dancing. Heck, you may even know that you have some “emotional intelligence” areas you want to improve on. Maybe you want to improve a relationship you have with someone. It’s all good. This might be a great chance to work in all of those areas.
Obviously, feel free to modify any of this framework to fit yourself, but here’s the experiment as I am going to set it up for myself.
You decide how long you want your sprints to be. Me, I’m going with one week sprints. Starting on Sundays and ending on Saturdays. The high-level backlog will be built prior to the first day of the first sprint. From that initial backlog, I’ll refine 1-4 items so I’ll have something to work with in my first sprint.
Sunday–Planning: determine what I want to tackle in the forthcoming sprint, and add tasks
Monday–Standup with myself
Tuesday–Standup with myself
Wednesday–Standup with myself; Refinement (refine a couple more items, look at priority, add to or remove items from the backlog).
Thursday–Standup
Friday–Standup
Saturday–Sprint review/Demo, Sprint Retrospective
To get started, there will have to be an event where we build our backlogs–the master list of all the things we can improve about ourselves in 1 week. Building that list itself is pretty interesting effort. I’m enforcing timeboxing on myself because 1) it will keep me from going too far down into a rabbit hole, 2) without a time limit, I’ll go into a “why am I so worthless?” sprial, and 3) because I find that a timebox helps me brainstorm–the panic of a deadline kicks in and adrenaline does its thang.
Just to get in the cadence of things, I’ll do that first backlog building and refinement session on a Wednesday and will continue that cycle every Wednesday after that. I’ll set aside 30 minutes to prioritize my backlog, (add or remove items over time), and to grab a 1-4 of the top items. To those, I’ll add some acceptance criteria –”What will attainment of this look like?” and making certain to include how this trait/skill/improvement can be demonstrated.–this is my parallel to “Working software”.
On Sundays, the actual first day of the sprint, I’ll spend 30 minutes planning the upcoming iteration by pulling 1 or 2 refined items from the top of my backlog. I’ll add the tasks that I’ll be engaging in to deliver that item to completion and in a demonstrable state by the end of the sprint on Saturday.
I’ll hold daily standups with myself–reviewing my board and addressing whether I completed the tasks I said I was going to complete the day before, and stating what I’ll be working on that day.
I’ll repeat that every day.
On Saturday, I’ll do my sprint review–demonstrating the quality(ies) I executed on during that sprint. After that, I’ll spend a few minutes retrospecting on how I did with my effort, what worked well, what tripped me up, and what things I can do to make this process work better.
Based on my previous experiment, I recommend a blend of improvements so that you do not begin to feel obsessive about one part of your life–balance is important. Maybe that is a lesson to take back to your development teams as well–or at least ask the question: “Does working in the same area of code or on the same application exclusively wear you down?”
Last time I tried this experiment, I focused exclusively on my spiritual well-being. Daily standups became more like prayer–which was great. Sprint demonstrations, however, became tricky because they were so intentional that they felt like they lacked sincerity. And as I mentioned earlier, some of the “features” I took on were way bigger than what could be accomplished in a week. Prioritization became a struggle. Defining “acceptance criteria”–
complicated. That, by the way, is a whole book in-waiting–currently spread between multiple notebooks, sticky notes, and bar napkins. Watch this space for more on that.
In any case, let’s try this experiment. My intent is to give this 8 weeks at which point I’ll stop and enumerate what was achieved. In the comments section, I’ll list out the things I am targeting for the week–Just a bullet item. I invite any readers to do the same. Each week, I’ll indicate success or failure–i.e. If I had to split a story or if I picked up new work. I may add a note about something I’m trying based on my retrospective. Again, I invite readers to do the same. At 4 weeks, I may write a post on the overall experiment.
What I hope from any of my readers is to hear your progress or observations about your own experiment.
Hmmm……. interesting…… would be cool if you include a glossary, too, for those of us who are lone wolf research programmer script kiddie types. Not sure how my life would look if I modeled MY personal development on the way I program (which I call externally-forced procrastination… “WE NEED THIS IN A WEEK. DO IT!!!” followed by 4 days of round-the-clock coding, a day or two of testing, and implementation. 🙂
Thanks for the suggestion! here you go
Glossary:
Acceptance Criteria: The “What am I looking at when this is completed to an acceptable level?” (usually) a bulleted list of things that exist that satisfy solving the user story’s problem statement. Frequently tasks are a natural offshoot of the acceptance criteria but multiple tasks may be required to accomplish one acceptance criteria. (A single task that satisfies multiple acceptance criteria is a developer having a really great day)
Backlog: this is your list of all the work you have assembled in your Self improvement project. You can’t do them all at once, so you will need to put them in prioritized order. You decided how you want to prioritize, but typical is the most value for the least work.. This requires quite a bit of discipline, because you may have something that you want to do because it will be more fun, but it might not have as much value.
Refinement: aka “backlog refinement” or “backlog grooming” This is the adding, removing, or re-prioritizing your backlog stories as well as the adding clarification to your problem statement or adding/clarifying acceptance criteria to the top few stories in your backlog.
Retrospective: stop and have the conversation (with yourself) What went well? What tripped me up? What are things I can work on in the next iteration? Of the things that went well, you list the things you can take action on to make sure that good thing happens again. Of the things that tripped you up, you list those otems that you can take action on to make sure they don’t happen again. Pick the top 1 or 2 and actively work on them in the next iteration.
Review: (aka “Sprint Review” or “Demo”) in software, it is where we pull in our customers and either share working software with them either by letting them have hands-on or by showing them working software in action. In our case, I’ll leave it up to you all for how you want to demonstrate your “improvement.” At the root of this whoel experiment, this is probably the most valuable part. It will help you write your stories and acceptance criteria more clearly, and it will help guide you in the “building” of whatever it is you are improving on.
Sprint: aka “iteration” the time box in which you will be working, usually anywhere from 1 week to 4 weeks. Scrum Agile call them sprints” because the team hustles through that period to get their work done. Then rests on retrospective/planning day. Since we are improving iteratively, I am borrowing the XP programming concept of “iterations.” I used the terms a bit interchangeably. Pick one for your own sanity and stick with it.
Standup: aka Scrum” in our case, you ask yourself what you finished yesterday, what you hope to finish today, and acknowledge if anything is blocking you from getting your task(s) completed. In a team environment, this is about sharing with and helping one another. In our singular model, it is about self evaluation and keeping yourself on target.
Stories: These are short problem statements that describe the things you are fixing. A canonical structure has been “As a (role or persona), I need (functionality) so that (expected outcome).” In our case here, a simple problem statement will suffice. e.g. “I cuss too much. I should Develop a plan to drop the F bomb less frequently.”
Tasks: Single events or actions that can be completed in roughly a day that move the effort forward in completing the acceptance criteria of your “story.”
Starting to compile a general list as ideas pop in my head. On Wednesday, I’ll prioritize and add some detail to the top few.