How We Plan

Goals

We try to keep our planning process as light and simple as possible, so that we can spend as much of our time as possible working on great designs. We recognize the importance of planning to keep us all focussed on the critical path, but understand that priorities and tasks will inevitably shift over time. Our plans are specifically built to flex and change as we learn and do more. Fluid's plans are ultimately shared by the community, and are open to contribution from all.

Types of Plans

The Fluid team has three types of plans, each providing an increasing level of detail about the project:

• The project plan: A high-level view of the goals and deliverables of the funded project as a whole
• Release plans: more detail about the deliverables we expect to include in each release
• Iteration plans: usually based on a two-week cycle, this lets us track individual tasks and assignments

The Planning Lifecycle

At the beginning of the project, we created a comprehensive release plan representing all the expected deliverables within the first two year. About six months into the project, we significantly reworked this plan based on what we'd learned so far.

Before work begins on each release, we prepare the release plan for the upcoming quarter. A release plan should contain all the high-level tasks required to deliver a solid, well-tested package. The release plan is intended to answer questions such as:

• Given the components, design patterns, and other deliverables we've got planned, what tasks are required to fulfill them?
• How long do we think it will take?
• Given our progress so far, what are the most important deliverables and tasks?

Release plans are generally created by the technical and design leads in consultation with the wider community.

Iteration plans, on the other hand, are devised by the various coordinators of our work streams: component design/development, UI design patterns, outreach, and testing. Before each iteration starts, the team reviews the current release plan to keep our goals in mind. Priorities for each two-week iteration are driven by the release plan, and dependencies between tasks are assessed. Each release task is broken down into smaller tasks that can be reliably estimated and shouldn't be larger than about 5 days or so.

We estimate using a concept of ideal days or units of work. An ideal day is defined as one with no distractions: if you could just focus on one task for the whole day without disruption, how long do you think it would take? For each iteration, we track the actual time spent and how many tasks were fully completed. Tracking our completion rate provides us with velocity, a realistic picture of how much work we can actually get done in an iteration.

Finally, at the end of a quarter, we check our progress against the project plan and adjust it accordingly.

Shared vs. Individual Work

Collaboration is at the heart of successful open source communities. Yet work is often driven by individuals with strong expertise and motivation in particular areas of specialty. Bringing volunteers into the fold can be time-consuming and challenging, particularly when they may only be able to contribute a portion of their time to the community. Our goal with planning is to strike a balance between sharing work and ensuring that individuals have the time and focus to follow through on their particular areas of interest.

Where appropriate, we assign tasks to individuals on the team. This helps to give us an indication of how busy everyone is, and recognize areas where we need to delegate or postpone. If you're interested in helping out with a task assigned to someone else, please feel free to get in touch with them (on list) and offer your assistance. We also try to specifically allocate certain shared tasks, providing a clear indication of how people can get involved.

Our planning team is not a inner circle. All are welcome to attend and contribute, but our goal is to keep planning meetings very short and simple. Please respect this.

Types of Activities

The Fluid planning process needs to take into account the different types of activities we engage in as a project team. An effective release or iteration plan strikes a balance between the various activities, allowing us to simultaneously 1) nurture a healthy community, 2) focus on quality, and 3) produce regular, useful releases.

Deliverables

Deliverables tasks are time-sensitive and directly result in products for release:

• User interface components
• Design patterns
• Framework code
• Documentation

Quality

Quality tasks involve important indirect activities--all the work required to ensure the quality and strength of our releases:

• User research
• Testing (QA, usability, accessibility)
• UX walkthroughs of non-core deliverables

Community

Community tasks encompass the work required to foster a healthy Fluid community, but don't necessarily result in concrete deliverables:

• Mentoring
• Working with participating communities
• Recruiting volunteers
• U-Camps

Responsibilities of the Planning Team

Before each iteration planning meeting, each member of the team should:

1. Check the release plan to remind yourself of the goals and deliverables of the current release
2. Update time spent and completion status for each of your tasks from the previous iteration
3. Ensuring tasks you'd like to do this iteration are in JIRA and correctly tagged

Throughout the iteration, coordinators are responsible for communicating the status of tasks in their work stream and checking in with assignees. If there are expected delays, identified dependencies, or a shift in priorities, let us know.

More detail about the planning process is available in the How to Plan an Iteration document.

Tracking Tasks

Once a release plan has been defined, each of the primary deliverables are entered into JIRA as components. Examples of components:

• "File Upload Component"
• "jQuery Keyboard Plugin"
• "Lightbox Component"

The main tasks for producing a deliverable, usually sourced from the release plan, are entered as top-level JIRA tasks. These help us to categorize and organize the detailed tasks over several iterations. Top-level tasks can be filed against several relevant components. Here are some examples:

• "User testing for the Lightbox" filed under Lightbox and UX: User Testing
• "Write a design pattern for uploading" filed under File Upload and UX: Design Patterns

As frequently as possible, break these high-level deliverables up into fine-grained tasks--generally no longer that 5 days worth of work per task. These tasks are then entered into JIRA as subtasks of the deliverable. For example:

• "Create a test protocol for the File Upload component"
• "Add progress bar to inform user of upload status"
• "Implement design tweaks based on results of user testing"

New or unscheduled subtasks should always be tagged as futuretask in the comments field so they are easy to find in JIRA.

Before each iteration, tasks that need to get done within the next couple of weeks should be tagged with the iteration number. For example, subtasks to be completed in Iteration 5 should be marked with iteration05 in the comment field.

Don't forget to set the task's Fix Version to the current release number.