Wednesday, 10 September 2014

update cadence & backlog management for Ubuntu on Phones


I wanted reach out to a broader group and discuss the update cadence for Ubuntu on Phones. In respect of our customer relationships I want to keep the discussion focused on relative time frames rather than specific fixed dates.

Starting with the availability of Ubuntu on phones we intend to provide monthly updates, with exceptions for security and other critical bugs. The content of said updates will be determined in a Scrum-like fashion by prioritizing existing backlogs as input for 2w engineering iterations.

We recommend a monthly release cycle in the first 6 months to be able to quickly react to customer feedback while balancing any burden that updates may cause (e.g. validation). Deviating from the recommendation in 2 week increments is acceptable upon request from the stakeholders/customer.

Update Cadence:
* System components:
 - OTA (over the air) updates in 4 week iterations, starting at retail date
 - Content
  - Critical/High bug fixes that are not leading to data loss or loss of major functionality
  - UX fixes
  - Prioritized feature backlog

* Click packages:
 - Updates are available immediately after the app author updates his app in the app store
 - Checks against supported frameworks will ensure compatibility with the then current system image

* Security updates & Critical Issues
 - Security updates will trigger a System Image or Click update at the time they occur and a fix is available
 - A security update of the system image will solely contain updates to components that are affected by the security issue
 - Any Critical bug that leads to data loss and/or loss of major functionality will also trigger an out of schedule update at the time the incident is understood, assessed and a fix/remedy is available

Backlog & Engineering Management
We intend to move more to a Scrum-type development model, where a small & well defined sprint backlog is managed by all stakeholders and will be implemented & delivered for an image promotion within sprints of 2 weeks length. The customers, via the commercial team, will decide when to trigger an OTA update. We plan to use following key Scrum elements:

Product Backlog
A list of features and bug fixes that is widely open for input from various sources such as Product Management, Design, the Community, early adopters, engineering etc pp.

Sprint Planning Meeting
The meeting where the Product Backlog will be regularly reviewed and prioritized in preparation of the upcoming engineering sprint. Representatives of the various functions (Commercial Team, Product Management, Design, Community, Engineering) will be conducting the meeting under the facilitation of a meeting chair/host

Sprint Backlog
A subset of engineering tasks serving as input for the upcoming engineering sprint, as defined in the Sprint Planning Meeting

We are curious to get your feedback to make sure this plan will not interfere with other parts of the Ubuntu ecosystem. Please follow up in this thread or contact me directly.