XPlorations

I've been interested in personal productivity systems for a while, so when Mark Forster introduced a new system called AutoFocus, I decided to create an electronic implementation. The system is a sort of todo list, in a organized as a notebook where each page has a list of tasks to do. There are rules defining the currently active page and task, and how you move your focus as you complete tasks. 

I began by analyzing the system (e.g., building a flowchart and transition diagrams to look at how tasks and focus move). I wrote some basic cards, and a series of screen sketches. For example, a task page will look something like this:

(The characters at the top and bottom of the page represent navigation arrows.)

Basics - Tasks

The first cluster of stories is centered around tasks and assumes all tasks are on the same page.

Notice that with just the above stories, the system could be a basic todo list manager.

Basics - Pages

The system is built around the metaphor of a notebook; we need navigation around the pages. The "current" page can mean two things: either the page you're currently looking at, or the one with a currently active task.

By the "rules," you're normally supposed to move the focus page forward (wrapping to the beginning) as you complete tasks. But there's a "don't be stupid" clause that says you can work where you need to.

Friendly Feedback

I want to push the system to a  point where I can get some friendly feedback.

First, I need to pick up the last major action required by AutoFocus:

Then I need to put the system somewhere others can see it:

Users

I can't just have one notebook out there for the world to see; I need to introduce the notion of users. I actually started with a card that said "User Management" but I expanded it to these:

Getting Real

What would it take for a beta test? I could probably defer "forgot password" and "update settings" but I have other work that would need to be done.

First, I'm asking users to trust the system and load in all their tasks. Paradoxically, I think if I make it less necessary to trust the system, people will trust it more. I'll do this by providing a means for them to export the tasks they've entered; then they know they can easily recover their work if they want to move on to a different system.

Another aspect of trust is the look of the site. I have some OK default icons, but the site will shine better with a new set.

It will have to be deployed to a public system:

"Home page" is a bit of a placeholder card. The bare minimum is to provide a login page, but in the long run it will need some explanation of the system and an appeal to register.

I could start with these on the home page but probably want them somewhere else.

I haven't decided how to fund the site, and I don't need to know to start a beta test. But eventually I'll need a revenue model fancier than "pray Google offers millions." There might be other ways, but the next two stories are what sprang to mind first.

Here's another story that could be big. I'm starting with a web site, but people may want to use their mobile phone to manage their tasks. This could be as simple as a special stylesheet, or it could become a whole separate application.

Sparkling Touches

These next stories are ideas I have that fit in the basic framework. They could be early upgrades.

I don't know what all I mean by page status, but it includes the date and whether this is the focused page.

Some tasks should just automatically recur once you complete them (e.g., "email inbox to 0"). I could put a flag on the task, or maybe find a more sophisticated approach.

Future Versions

I have a number of stories that aren't so well defined - the fuzzy ones.

People might want to pull out separate lists that aren't managed by the AutoFocus rules. I don't know if this needs to allow multiple user-created lists, or how that will work.

Once people get a lot of tasks, they may want to find a particular one:

A tickler is a reminder system that lets you schedule tasks out in the future. ("43 folders" - one for each month and one for each day number in the month - is a classic paper form.) Some people just put tickler tasks in their calendar, but I think it would be handy to have a tool that automatically brings them in to the task list as appropriate. I want to make sure to include the notion of lead time - I might like to be reminded that today is my sister's birthday, but I really need 2 weeks notice so I can get her a card or gift. (And I want that reminder as a task, not a phone or email reminder.)

Many tasks have a standard set of sub-tasks. I'd like to put them on a checklist and have them brought in on demand. The easy form is a "parallel" list - put all tasks on the list.

The more classical form is to do the steps in order. When one step is completed, the next one should be scheduled.

People might like some sort of analysis, or it might be useful in supporting the system.

And I have a last one that's totally open. It's really more of a goal than a concrete story. It might be met by paid advertising, blogs, FAQs, help pages, email reminders, you name it.

Analysis

I feel good about this set of stories. They capture the bulk of what I want the system to do.

I used a simple "headline" form for the story titles - just a short verb phrase. I know the domain, and it's generally obvious who the story is for and what it's for, so I didn't feel the need to put them in the "As a ____, I want to ____ so that ____" form.

The stories came in three batches - the early task and page stories (with a couple sparklers), user and deployment stories, and the others. I developed them in combination with repeated sketches and analysis.

Another way to look at stories is to look at them versus the INVEST acronym (from my earlier article "INVEST in Good Stories"):

• I - Independent. The stories mostly stand alone from each other. The dependencies tend to be domain-related rather than technical. (For example, it doesn't make much sense to have a logout story before you have a login.)
• N - Negotiable. The smaller stories are straightforward and well-defined (though they have some room on the details). Bigger stories have a lot of flexibility. Plus, this is a one-person project so there's not much problem there.
• V - Valuable. Each story adds a clear bit of functionality to the system. The most technical story ("deploy") still makes sense to a product owner.
• E - Estimable. I have a good sense of which stories are well defined; even for the fuzzy stories I can make educated guesses about the order of magnitude.
• S - Small. Stories ready to schedule (closer to the top of the list) are generally hours to a few days work. That's appropriate. Later stories are bigger; that's ok too. When it gets time to implement them, I'll break them down into small stories as well.
• T - Testable. Ready-to-schedule stories are testable; the fuzzier stories will need more explanation and analysis before we could write a test.

If I look at the list of stories as a release plan, the order is generally good. (There are a few stories that could move down in priority.) But one thing stands out: deployment could be moved much further to the top. It could be the second story: a simple list of active tasks might be useful to somebody (perhaps as a status report or proof of concept). It's easier to deploy when the system is still small. And it's a key to getting feedback.

Resources

• Extreme Programming Explained: Embrace Change, 2/e, by Kent Beck and Cynthia Andres. Addison-Wesley, 2004.
• User Stories Applied, Mike Cohn. Addison-Wesley, 2004.
• "INVEST in Good Stories", Bill Wake.

Copyright 1994-2010, William C. Wake - William.Wake@acm.org