• Intro
• Downloads
• Community
• Development
• News
• TALK

maemo.org sprints

Revision as of 21:58, 4 August 2009

A sprint is the culmination of a month of development. maemo.org development is handled through a scrum process (scrum is a development process which utilizes month-long development periods that have a set of tasks to be completed by the end of the sprint) with a planning meeting held on IRC in #maemo-meeting, and daily status reporting and task-specific progress reporting on that Sprint's wiki page.

Anyone interested in following the maemo.org development process should review the current month's Sprint page and consider attending the IRC meeting.

Process

The scrum process is adaptable, simple, and ease for newcomers to pick up. Development is broken up into month-long periods (sprints). A number of tasks are committed to each month-long sprint to be completed by the end of the month. A planning and review meeting is held at the beginning of each month where progress is reviewed and new tasks (and, often, incomplete tasks from the last sprint) are committed to the next sprint. Daily progress reports are also posted to that month's wiki page.

Each task is assigned a MoSCoW prioritisation:

• MUST
• SHOULD
• COULD
• (WONT)

Sprints

Note: Sprint 1 of the 100Days was handled internally.

Development is broken down into monthly sprints with an IRC review and planning meeting at the beginning of the month of each sprint.

These are all of the previous Sprints:

Tasks

For more information about bug tracking and priorities, please see Anatomy of a Bug and Life Cycle of a Bug.

A written description of every proposed and committed task for maemo.org will be provided in a wikipage for that task. The task page should outline the plan for that task and centralize any relevant information for that task. This ensures that everybody agrees on the same plan for the task, and provides a centralized place to track the specifics of the development of that task.

All tasks willing to be commited in a maemo.org sprint should have either:

• A proposal in a wiki page starting with "Task:" using the Template:Task by adding {{task|proposed}} to the top of the task's page.

(i.e., if you want to put together a task for documenting the maemo.org Sprint procedure, you might create a new page titled Task:Document the maemo.org Sprint procedure and add {{task|proposed}} to top of the page.)

• Or a bug report in the maemo.org Website classification with MEDIUM priority.

Only tasks with wiki pages can be committed for a Sprint.

Once the task is committed for a sprint, the task template should be changed to {{task|accepted}} and then {{task|ongoing}} once work begins. As work on the task progresses, the wiki page should be updated to reflect the current progress. Once work on the task is completed, the task template should be changed to {{task|completed}}.

Planning meeting

The planning and review meeting is held on the first Tuesday of the month at 13:30 UTC. It will be announced on the maemo-community mailing list. The meetings typically last between 1.5 and 2 hours. If you are unable to attend, logs are posted to the website usually by the next day.

The channel is unmoderated for the duration of the meeting, but extraneous and off-topic comments and conversation must be kept to an absolute minimum (#maemo can be used for chatter). There is a lot of information being exchanged between a lot of different people, and chatter slows us down and confuses the meeting.

Outline

Direction of the meeting is typically handled by either Nokia's community representative or one of the Community Council members (depending on who is available).

To save time, some preparation work should be completed before the start of the meeting:

• The meeting facilitator creates a new sprint page and links it to the sprint meeting announcement.
• Task owners leave the final status of their tasks in the sprint:
  • Task should be marked as DONE (green background) or, if not DONE, % of completion (with a red background).
  • Comment for posterity summarizing what was done/left.
  • Update the status banner of the wiki task page ({{task|ongoing}} or {{task|completed}}).
• Facilitator moves all the incomplete tasks to the table of the new sprint.
• Anybody willing to propose a new task needs to list it in the Proposals page.
• Anybody willing to push a bug needs to get it to MEDIUM priority (request it in the bug itself if you don't have permissions).

Meeting agenda:

1. Progress of the past sprint:
   1. Only general/exceptional comments, since the progress as such is left in the table and daily reports.
   2. Any objections to a task being marked "DONE"?
2. Planning of the next sprint:
   1. Any task moved from the previous sprint considered not appropriate for the new sprint e.g. better moved back to the backlog or dropped?
   2. Tasks from the backlog to be committed.
   3. Tasks from the Proposals page to be committed, to the backlog or sent back for improvement.
   4. Any pending HIGH bugs to be dropped to MEDIUM, LOW, or WONTFIX?
   5. Any MEDIUM bugs promoted to HIGH and committed to the sprint?

Just to clarify: no new tasks and no LOW bugs taken if they were not proposed/promoted before the meeting. They don't have to be committed to be worked on. You can always work on them out of the official sprint.

Actions to be taken after the meeting:

• Update the tasks and bugs tables according to the meeting agreements.
• Upload meeting log and link it from the new sprint page.
• Review old and new committed task pages, making sure they have the correct status banner.

Daily reporting

Having daily standup scrum meetings when working online is difficult, so, Instead, developers involved in the Sprint will report their daily progress (assuming they're working on anything Maemo-related) in a workstream.

The preferred way to report day-to-day activity progress is through the Qaiku #maemork channel (see Bergie's blog entry). Alternatively, a thread (per-task) on tmo.

All updates should include either the task ID (of the form <year>-<month>-<id>) or "BAU" (Business As Usual).

The reports should be reasonably short and clear workstreaming entries, containing things like:

• What have I done since my last report. This is useful for others to see what is the progress.
• What are the obstacles I'm facing. This is useful to highlight problems (e.g. non-evident dependencies) where others can help.
• What is my plan today. This helps you to get organized and provides an orientation to others working in related tasks.

The reports are necessary for other developers and interested community members to be able to follow the Sprint's progress, so reporting is highly recommended for paid contributors, and suggested for volunteers.

Task progress table

A simple table is used to provide a quick, color-coded overview of the current progress of the committed tasks for the Sprint. Task owners will updated the color-status, percent completed and comments as they work on their tasks.