Yes, I will get to my idea of ScrumOfOne, covering each role, ceremony, and artifact, but a few points should first be mentioned.


The following is the definition I use for Scrum.

Scrum is a framework for development that embraces change via transparency, inspection, and adaptation.

Scrumming unto self requires discipline. Yet, ‘life’ happens. Things come up. “Oh man, I totally forgot there was that networking event I said I would go to, so there goes my evening.” Distractions are juicy. “Oh man, that’s right, we haven’t seen each other in a while, buddy, or we just met, new buddy, so we should totally hang out this weekend.” You get tired. “Oh man, that day at work or after-work jog along the Charles ended up being longer than planned, so I totally just want to pass out right now.”

Executing a game plan in an uncontrollable environment is a challenge, just like at work. This is why I give myself two weeks to ‘implement functionality’ instead of a day, leaving room for unexpected impediments, or a month, leaving flexibility to redirect personal growth.

Scrum Livin’ also provides a milestone between sprints at which to recenter. During sprints, I try to make it light-weight enough to not feel like a lot of overhead, yet thorough enough to set stuff to get done. I track said stuff via my HTC Droid Incredible iPhone, the main use case for my smart phone.

The transparency is very helpful in documenting daily what is getting done and how quickly. The inspection is insightful in determining the feasibility of completing current and future stories, and yes, I learn about myself in the process. The adaptation comes in the form of rearranging my schedule, shifting focus, clarifying acceptance criteria, setting controls in place, and realizing I can’t control everything. The result, believe it or not, is increased inner peace.

This is what I love about ScrumOfOne – I have developed a multi-faceted vision for myself, where its evolution is encouraged! Its refinement is openly managed. Every day, I am proactively working on my path on this earth, my journey in life. Doesn’t this sound like a definition of happiness? I know… it’s pretty deep.

What you read below is my current pre-fatherhood implementation, a work in progress, thus dynamic. I invite your constructive comments.


Since becoming a father, the rigor outlined below has since become… unsustainable; however, I am keeping it documented here so y’all see a system that has worked, once upon a time, and maybe in time once again. What is my system now? I shall pull from a recent blog post.

Though not formal, I’ve learned to use the small gaps in daily activity to reflect and prepare, reducing feedback loops and extracting Kaizen where appropriate.

Though not detailed, I now frequently use Siri & dictation & the iCloud-backed-up Reminders app on my iPhone as just enough process to make me effective. The different lists in the app serve as different ‘product’ backlogs. Weekly to daily ‘Sprint’ backlogs are established via setting a date per reminder, so the highest priority items are visible on my lock screen. My working backlog is in my hand at the single push of a button. With ‘the next’ literally at hand, my focus is freed to embrace ‘the now’.


As a ScrumMaster, I lead the ceremonies and curate the artifacts. I remove impediments (simply asking the question of if there are any does wonders) and improve the team of me. Creating this page, sharing on this blog, and cultivating a community are all part of this effort.

As a Product Owner, I take my dreams, in all its various shapes and sizes, and mold them into stories that are independent, negotiable, valuable, ‘estimatable’, small/specific, and testable. I prioritize them based on value to me in any one of numerous aspects, be it financial, cultural, musical, physical, etc. I craft acceptance criteria that are essentially test cases that should be passed at the demo. I give myself permission, without feeling bad, to work on things outside of the sprint as they arise because they most likely serve me in the greater picture. This is important; if a story is not done come sprint-end, I know why and am at peace with it.

As a Team Member, I determine the ‘how’ and pull tasks based on the nature of the coming day. I actually feel good getting stuff done not just because I get to cross something off a list, but because I know a task is part of a finite set of activity to complete a story that enables me to enjoy a new and clearly defined piece of functionality. I reap the benefits directly and tangibly. Appreciating this connection subsequently injects a modicum of excitement into each task.


The Product Backlog is its own Google Doc, each long item consisting of a story, its acceptance criteria, and what its completion enables me to do. Each item is also prioritized and sized using Fibonacci numbers.

The Sprint Backlog is its own Google Doc, where list items are either stories pulled from the Product Backlog, sized at a maximum of eight points, or tasks, explicitly derived from the story acceptance criteria, created during Sprint Planning. If a task is associated with story ‘b’ and has 4 hours left until its completion, then the list item is prepended with ‘b4’. Thus, a quick scan of the Sprint Backlog Google Doc shows how many tasks are associated with any particular story and the hours left, both throughout the sprint and at the day’s planning during the Scrum. Until I find or write an app I am happy with, this hack for using simple lists does the trick. From doing this for a while, I have lately taken on the practice of crafting stories to be smaller such that also managing tasks seems like overhead overkill.

While I do keep track of velocity, I don’t yet have a Product Burndown chart or a Sprint Burndown chart. I’m avoiding the overhead associated with throwing things into Excel for now. A visual representation of progress should be more easily created if I decide to carve out a space for it on my whiteboard. So far, using Google Docs, keeping stories small, and clumping the done stories together all help in seeing how far along I am with the sprint stories.


The Sprint Planning meeting is currently a little tedious as I expand the acceptance criteria from a story (one list item) into tasks (many list items), but this does save space in the Product Backlog. This also forces time to be spent understanding the story as I type out each task. Before ending this ceremony, I visualize each of these stories as done, feeling the benefit of their completion. This last part helps because if I can’t see what I’ve got lined up getting done, then maybe I am over-committing or working on the wrong things.

Sprint Focus Points are what I set before stories for the sprint. This is a small list of reminders or affirmations I get myself to review daily that include what I would like to practice (relax shoulders) and what I derive from the recent retrospective ‘adapt’ section

Every morning, before I start my day, I conduct the Scrum with/unto myself, standing and asking the three questions out loud. Identifying possible impediments makes what I decide to chew off for the day more realistic. This also provides a moment to reflect on the estimation of task duration. Before ending this ceremony, I visualize each of these tasks as done. Again, this helps with dealing with over-commitment.

There are a few quick activities, more focused on personal development than getting things done via Agile, which require a daily frequency, so I fit them in on both sides of the Scrum. Pre-Scrum, I walk up to my bay window, with Mass. Ave. below and Back Bay beyond, take a deep breath, hum my theme song, and say some Wayne Dyer-esque affirmation. (“Good morning, Boston. This is my day. Nobody can take away my joy. Let’s make waves today. Kick some ass.”) This gets me in a pumped and confident state to enjoy the day. Post-Scrum, I review my Sprint Focus Points and note a few things about the day before, like where & how I spent money, as well as one thing I learned.

At the end of the sprint, the Demo thus far consists of seeing if the tasks crossed off indeed constitute the completion of the story based on the acceptance criteria and some minimal Product Owner discretion (Did I really need to buy beanbag chairs as a task for the story of furnishing my place to host a party?).

The Retrospective is long and very structured. I state the purpose of the Retrospective, determine the current velocity, list out major events during the sprint, discuss impediments & the sprint focus points, establish what to keep & start & stop in terms of process during the sprint, filter it all into specific steps to adapt into future sprints, and conduct a retrospective of the Retrospective.