Continuing with the work to refine and improve how we build Ubuntu in an open, transparent, and collaborative way, I want to take a few minutes to discuss some work going on to improve the regularity of our planning and the benefits this brings.

Traditionally planning for Ubuntu has worked like this.

* We ship a release.
* Shortly before a release we rapidly prepare blueprints for the next Ubuntu Developer Summit (UDS). Everyone is welcome to participate.
* We discuss topics at the UDS and jot down work items into blueprints.
* We then execute on those work items over the course of the six month period.
* We track this work on [status.ubuntu.com](https://status.ubuntu.com) and use burndown charts to visualize this progress.

While this has served us well, there are a few problems with this approach. The most notable issue is that we work in software, and a lot changes in software in a six month period. This means we define a set of work items, prepare the burndown, and then if requirements or direction changes it can be difficult to reflect those changes across our community and we have to go and postpone a bunch of work items and re-build our burndowns. This means that even though the changes are made to open blueprints, it can cause folks across our community to be out of sync. It also presents the misconception that everything at UDS is locked in for the duration of the six month cycle. If something changes in our strategy or a new opportunity opens up, it can be difficult to change course with everyone on the same page.

Solving this is part of our theme of making Ubuntu engineering as transparent and agile as possible.

One approach we are experimenting with in the Ubuntu Engineering Management team at Canonical is to increase the regularity and transparency of how we plan. Instead of locking in every six months we will do it like this:

* We host the virtual UDS (vUDS) every three months and use the event as a means to plan out the next three months of work. All discussions are open, everyone is welcome to participate.
* Blueprints will be used to track that work and work items will be divided up into monthly milestones.
* On the last week of every month we will review the work performed in the last month to see how well it was completed and then plan the forthcoming month’s work. This provides an open opportunity to identify blockers, define new goals, and change coarse if needed.
* A new burndown chart will be generated on [status.ubuntu.com](https://status.ubuntu.com) and we will host a Google+ Hangout presenting the goals for the next month to ensure that everyone is fully up to speed on what is going on.

Now, to set expectations clearly: this is just an idea for how to improve this workflow, and we are doing it for the first time this week, but the idea is that it will dramatically increase the transparency of which teams are working on what, making it easier for others to (a) know what is going on and (b), participate in areas of interest.

My team is currently preparing the work items for April and you will be able to see the final burndown [here](https://status.ubuntu.com/ubuntu-raring/canonical-community-ubuntu-13.04-month-6.html) when it is complete. From there you will be able to see all the blueprints.

I will provide plenty of feedback on what is working well and less well, and your feedback is welcomed, as ever, in the comments.

## Building Re-usable Processes

As I mentioned in [my previous blog entry](https://archivedblog.jonobacon.com/2013/03/18/recent-ubuntu-community-refinements/), we want to make virtual UDS an event that is repeatable and useful for not just UDS but also for domain-specific events too (such as a LoCo themed UDS). The goal is that this event format is repeatable for our wider community.

Likewise, the monthly planning process is also designed to be repeatable for our wider community too, making it simple to get everyone on the same page for planning and executing on awesome projects.

As ever, feedback is always welcome, but I think this combo of a wider planning event every three months combined with monthly work item sync-ups and planning will result in a pretty effective formula for helping Ubuntu to be as effective, transparent, and collaborative as possible.