At Linaro, one way or another, we do a weekly report cycle to our groups, members and Linaro.

This can be done in multiple ways, but it's always good that we do at least one of them, to make the lives of project managers, tech leads and member services a bit easier.

Every month, we also use that information to prepare an /wiki/spaces/EMR/overview, so having accurate information on your progress is important to report them to our members.

For our group, we have chosen to use Jira directly and update the stories we're working on as often as necessary. This is mainly up to the engineers, but it has to be done at least once a week.

Jira update

Now that we're all using Jira Kanban boards, we can see our progress as it happens. Adding comments directly to the tasks, moving them across the board and creating new tasks on the fly is the best way to report your progress without adding bureaucracy to the process.

Furthermore, project managers and tech leads scan the Jira updates (using weekly and monthly filters based on changes to cards) to know what happened. These updates are scanned by hand and scripts, and they update other project management structures, "Health Check" and "Engineering Update" reports every month.

Four Levels

Our Jira has 4 levels:

Initiatives

• Major projects, discussed at the TSC level with vague descriptions and general ideas.
• Owned by the TSC representatives
• Long term (year scale)

Epics

• Breakdown of initiatives, with concrete expectations, definite tasks
• Owned by the main engineer working on it (or tech-lead in case of multiple)
• Medium term (month scale)

Stories

• Breakdown of epics, short self-contained tasks that describe how epics will be done
• Owned by the engineer working on it
• Short term (week scale)

Sub-tasks

• Breakdown of stories, only used if the stories are too complex/big
• Owned by the engineer working on it
• Very short term (day scale)
• These are not required and not encouraged

Stories are the important ones, the ones that will eventually have patches upstream, tests proving it's done, documentation written somewhere (either upstream or on Linaro's wiki). They're also the ones that show how the implementation of the Epic needs to flow, so feel free to use relationships like "depends on" or "blocks" to other stories, even in other epics. They can be created at any time and we encourage people to create them even if they may not be worked on. This is your brain-storm process (like sub-tasks) and it should help you organise your thoughts and demonstrate your work, and not hinder you by introducing bureaucracy.

Epics shouldn't change too much on their lifetime. They're usually created by the tech-lead, together with the engineers that will work on it, in order to show the TSC that we're working on the tasks and to show some progress.

TSC members only see Initiatives and Epics, so we keep the noise down on that level and crank it up at the Story level. Right now we update the members with a "Health Check" card and the "Engineering Update", so the epics are mostly for organisational purposes. But they still shouldn't have noise, so we do not update them with development comments. All of that go into stories.

Basic Rules

Managing Epics

If you own an Epic, make sure the stories beneath it are up-to-date and reflect your current work, at least to a week granularity. Feel free to update your stories once a week or every hour, whatever makes you more productive.

Do not update Epics, only use it to create new stories. Create as many stories as you need, whatever makes you more productive. Feel free to resolve stories that won't be worked on. I will look at all the resolved tasks weekly and close them or ask you questions (like where's the docs, commit link, how did you test, etc).

If you finished working on an epic, or need to create a new epic, talk to me, we'll do that together. This is intended to reduce the noise at the TSC level.

Updating Stories

The updates are better if they're done as soon as you finished a step in your work, or at the end of each day, so that we can have an idea of pace. But that's not always possible, so we shouldn't create strict rules around it.

The minimum amount that is required, however, is at least one update per week, on the cards that you have actually worked on. Simple comments, like "still progressing, now implemented X and Y", are more than enough.

Also make sure to keep the workflow correct. Only keep In Progress what you're actively working on that week, and move to Upstream Review what's waiting on the community or back to TODO what you have put on hold.

Important: Do not update work hours / points on the Jira cards. Those are completely ignored by everyone and every script. Instead, just keep the right cards in the right columns and that's more than we need.

Plans for next week

Open tasks are unassigned, meaning no one will work on them any time soon. Once you plan on working with something, assign that card to you (or create a new one and assign it), so that it appears in your TODO column.

You can keep cards in the TODO column for weeks, as long as you have enough in the In Progress and what's in there is more important than what's in TODO, that's perfectly fine.

We also don't care much about the priority field in the cards, but you can use it for your own benefit.

The only thing that matters to us is:

• regular comments means regular work being done
• cards to be in the right columns

Problems and blockages

All problems and blockages should be reported immediately at the appropriate channels, copying your internal development list and your tech lead.

Infrastructure problems need to be reported to ITS, Lab and Systems teams or other teams in LEG. Builds and releases reported back to Builds, toolchain, kernel or even LAVA teams.

Long term blockages warrant moves to the Blocked column, but only after you have reported and followed up in the right channels.

These mark tasks as completely blocked, meaning you cannot work at all without the other teams removing the blockage, and will fire a salvo of urgent requests across all involved teams.

Do not move them to the Blocked column unless:

• The task being blocked is urgent or the most important task you have In Progress, and
• The blockage will not be resolved by waiting, ie, needs working with other teams before solving it.

Overall

The following picture summarises the usage of Jira:

And the three points below summarise the weekly cycle updating Jira:

• Constantly update cards with comments and workflow movement (drag&drop on Kanban board). At least once weekly, possibly once daily, preferably as you complete blocks of work.
• Make sure the tasks are in the right column. Pay attention to the roles of the columns, and use them wisely. You should do that at least once a week.
• Use mailing lists, IRC, email, Hangouts for all other updates, conversations, collaborations and to interact with other teams.