r13 - 24 Jul 2007 - 09:51:20 - KatieCappsParlanteYou are here: OSAF >  Projects Web  >  ChandlerHome > ZeroPointSixPlanning > ZeroPointSixNonCodeReleaseItems > PlanningProcess

Current 1.0 Proposed Plan

This visual below shows a snapshot of a possible path to get us to a usable Chandler 1.0. The major feature areas are listed across the top and individual usability stages are indicated by colored boxes. The evolution of this is further explained in the "background" section below.

1.0 Stickie Plan

Since long range planning is difficult to do accurately, we expect to tweak with this on a regular basis depending on how priorities change from release to release. However, this does allow us to think about how we might stage certain features at a high-level and what dependencies there might be. 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? As we explore some of these questions further we will continue to iterate on this plan and capture it visually at regular intervals.

Current and Future Planning

For every dot release we maintain a central planning page. This page starts out with a simple list of release tenets and evolves into an extensive document with detailed feautures lists and links to specs, architecture documents and release planning pages. The current 0.7 planning page can be found below.

Historical planning pages...

Planning Process Background

The planning process at OSAF has evolved considerably over the life-cycle of the project. Originally, much of the planning followed a breadth-first approach of making incremental progress across all areas of the product. We would start with an initial list of proposed features and converge on a subset that can be implemented in approximately a 5-6 month time-frame. Most of the activities centered around planning for the current dot release. Extending this into a longer range plan was a challenge. It's often difficult to predict schedules accurately more than several months in the future where the dependencies and details are less clear. Although we have a good idea of the overall vision for 1.0 mapping out all the features over a period of several years seemed like a fruitless task.

About a year ago, the product team adopted a 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. This was basically a visual realization of the bottoms-up release planning that we were already doing. At this level, the features are fairly coarse-grain. We estimate the size of a "stickie unit" to be approximately one month of work for a developer. Some features are considerably less than one "stickie" and some will be more but for planning at this level, it provides a baseline from which to start. 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.

We have found this technique to be quite effective. The graphical and easy-to-change layout allows us to group stickies in a variety of ways that help us answer questions and spread the workload. We can look at the distribution of work across teams, map stickies to resources and compare the number of stickies for the current release to what we have accomplished in past releases. Over the course of using this technique for a couple of releases, several trends have started to emerge.

Our application centers 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 feature area or "track". The feature areas we have defined currently are as follows.

  • Calendar: calendar app with all the bells and whistles
  • Email: basic email features to support the dashboard and sharing
  • Dashboard: version 1 of a new paradigm for task and project management
  • Dev Platform: building the framework for 3rd party developers to extend chandler
  • Sharing/Collaboration: innovative ways for individuals to collaborate in small workgroups
  • App Basics infrasture work for supporting tenets and basic app polish features that "complete" the app

Each of these tracks in turn has distinct stages of usability in the product which can be described by a specific set of criteria. We have identified five stages of usability as listed below.

  • Embyonic: infrastructure, no user interface
  • Initial: test/minimal user interface, validates the infrastructure work
  • Plausible: basic user model is in place
  • Dogfood: testable user workflows, basic usability without polish and discoverability
  • Usable: usable workflows for early-adopters

We found that individual stickies can map to both a track and a phase and the high-level goals of a specific dot release can be articulated by a set of tenets which represent stage of usability for a particular feature area. This makes it much easier to focus our effort and priorities around a clear set of goals for a release. To extend this a bit further, if we mapped out all the stages for all the feature areas in the product we could articulate a product roadmap which is displayed above.

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r13 < r12 < r11 < r10 < r9 | More topic actions
 
Open Source Applications Foundation
Except where otherwise noted, this site and its content are licensed by OSAF under an Creative Commons License, Attribution Only 3.0.
See list of page contributors for attributions.