About a year ago, the product team at OSAF adopted a planning technique we refer to as “stickie” planning. As it sounds, this involves listing product features onto post-it notes, mapping them onto a whiteboard and assigning them to a particular dot release in our product plan. The features are described are fairly coarse-grain. A stickie might be “calendar month view” or “email forward and reply”. We estimate the size of a “stickie unit” to be approximately one month of work for a developer. We realize that the scope of some features are considerably less than 1 “stickie” and some will be more but for planning at this level, it’s adequate to get a ballpark stake in the ground for our next release. It isn’t until we start to drill down and scope out the details that we can understand if some of these projects are larger or smaller, at which point, we return to the stickie board so to speak for another round of refinements.

More recently, we have taken this process one step further in an effort to use our stickies for a longer-term planning initiative. Our application pivots around distinct end-user workflows. Stickie planning around these workflows helps us ensure that our dot releases aren’t simply a bucket of features that may or may not be useful to anyone, but actually meet a coherent set of user needs. This coherent set of user needs can be described as a workflow track. Each of these tracks in turn has distinct stages of usability in the product. By mapping stickies to a track and a phase, we can articulate some notion of a product roadmap. So with a bit of html and css wizardry, what might this thing look like?

NOTE: Until we fix some bugs, this timeline is best viewed using Firefox.

Roadmap

This visual shows a snapshot of a possible path to get us to a usable Chandler 1.0. I say “possible” since we expect to tweak with this on a regular basis depending on how priorities change from release to release.

Across the top are the workflow areas we have identified so far: Calendar, Email, Dashboard, Dev Platform, Sharing/Collaboration, App Basics (a mix of infrastructure work and basic product gestalt).

Each of the colored boxes represents specific stage of feature area usability.

Embryonic: infrastructure in place with no UI
Initial: test UI
Plausible: user model is in place
Dogfood: testable user workflows
Usable: usable workflows for early-adopters

The sub items in each box list what features (stickies) we think we need in order to reach that stage of usability in a particular workflow track (ie. Plausible Sharing). For example, can we call Email plausible without forward and reply? Probably not.

Another benefit of stickie planning is that the graphical and easy-to-change layout allows us to group stickies in a variety of ways that help us answer questions and load balance. Are the different workflow tracks progressing at fairly comparable rates (even if they are at very different stages of usability)? Is work being distributed across the development team evenly? It also helps us recognize patterns and dependencies. In the past two releases, we’ve been able to finish x-number of stickies, what’s the likelihood that we will be able to accomplish more in future releases? Is there an upward trend in stickies across releases? Can we get to a usable Dashboard without first having at least Plausible Email? If not, how can we move these stages around so the features roll out in the right order?

So what’s next in the evolution of this process? We will continue managing our live “stickie” board, capturing a proposal at regular intervals and hope that we don’t run out of post-it-note colors to choose from.

Highlights

• Chandler feature complete date Oct 12. Bug count continues trending downward (down 40 last week).
• Significant performance improvements in creating a calendar, also other areas.

Design

• Progress: Continuing bug councils. Dogfooding Chandler daily. Brainstormed Chandler branding ideas.
• Plans: Branding and landing page work. David Allen discussion next week.

Applications

• Progress: Bug fixing (still including tasks/features): 20/week
• Plans: Fix 40 bugs targetted to M6

Services and Dev Platform

• Progress: Performance improvements (creating new calendar and more general improvements). Finished i18n framework improvements for 0.6. Sharing integration testing and fix work (Chandler speaking to Cosmo 0.2)
• Plans: Finish recurrence. More performance work. Bugs.

Build and QA

• Progress: Tested checkpoint build on Mac. Added performance tests.
• Plans: Get functional tests working on Tinderbox. Regression test old features on current builds. Iterate on Tinderbox performance number presentation.
• Personnel: hiring junior QA person

Cosmo and Scooby

• Progress: Demo’ed week view for Scooby (work in progress not completely functional). Fixing interoperability problems in 0.2 as Chandler integration testing proceeds.
• Plans: Pull out Cosmo Repository for use by Scooby and make it an API. Add a data backend to Scooby week view demo.

IT

• Progress: Handed off phone admin. Finished project to choose hosting for Corporate Leavers site. Handled 39 tickets in one week.
• Plans: Lots of alarm issue followup. More server backup and demo broadcast project work.

Community and PR

• Progress: Mellon report drafts. Tantek Celik’s Microformats talk.
• Plans: Prepare demo for Educause panel. More Mellon work.

I mean it: I started to dogfood Chandler seriously since Friday September 23rd!

So far, I’m fairly happy with it though I ran through a couple of crashers that I carefully walk around in my daily usage. I’m avoiding anything too adventurous with recurring events (like sharing or moving between collections…). But despite the bugs, the great news is: Chandler is rapidly becoming usable, there’s nothing I was doing with iCal I found myself not being able to do in Chandler. I can save my data (in .ics) and read them back with no loss. This last aspect alone is paramount when dogfooding and I’m glad to report I haven’t lost anything so far (knocking on wood…).

So, what does it mean to “dogfood” Chandler?

• Download Chandler of course: at that point, considering the rate of bug fix and that we’re not rearchitecturing anything, I recommend using the latest checkpoint (top link on the download page).
• Run Chandler exclusively: I know it’s hard to get rid of old habits but, if it’s hard for the enthusiasts, just think about how it will feel for others…
• Take notes of every behavior or issue you find when running Chandler: mild annoyances, UI defects that bug you, anything that make you want to leave Chandler and start iCal again… Those are things that are not necessarily bugs and that you may want to discuss with someone on the team. The design mailing list is a perfect place for that kind of discussion.
• Report bugs religiously: we have a great tracking system and we use it! Don’t just send an e-mail out and hope someone else will track the problem.

I’ve been logging quite a few bugs since Friday but I don’t feel bad about it: this is exactly where we should be right now.

I encourage everybody at OSAF to start dogfooding. This is important we get some mileage among ourselves and feel confortable with the application before we roll it out to the World with fanfare.

After years of development it feels strange that people may actually use our stuff but this day is actually really really close now… and it’s a pretty exciting place to be.