Skip to end of banner
Go to start of banner

Weekly Cycle

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

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.

The two main update methods are: Weekly emails and Jira update.

Weekly emails was the style most teams used in the past, but they're now redundant with Jira updates, so we strongly recommend you to use Jira directly.

Here are the explanation of both, however, so you can interpret other people's reports, if they still come in that fashion.

Weekly Email

This is simply an email that you should send to your team's mailing list on Fridays, outlining what you have worked on.

You should not use this style from now on, but understanding it will make the Jira style more clear.

Style

The format is usually known as "3x3", with three sections:

  1. What you have worked on, including references to Jira tickets, short comments and the amount you've worked on each of them.
  2. What you plan to do next week, including continuations, new tasks, holidays, etc.
  3. Any serious problems or blocking issues, to raise awareness that you may not be performing as optimally as expected.

Jira + wort time

Linking the Jira card (by title, ex. HPC-123) and a short description of what you've done.

Also, this format has a "10/10" time slot, with each slot being "half-day", so that you have 2 slots per day, 10 slots per week.

Those times are approximate and only meant as a general idea of proportional work, not to actually measure time worked.

Most of those reports contain a proportional amount of "time wasted" in meetings, emails, travel, infrastructure.

An example of such a report would be:

This week
=========
* [HPC-123] Updated machines to new OS [1/10]
* [HPC-234] Continue working on SVE libraries [4/10]
* [HPC-345] Rebased patch, still waiting for reviews [1/10]
* Meetings, emails, infrastructure [2/10]
* Friday off [2/10]

We usually try not to waste more than one day a week on meetings. If you have too many meetings or you're wasting too much time discussing on lists and reviewing patches, make sure you sync with your tech lead to reduce that time.

Plans for next week

These are normally simple and often obvious tasks, but show which of the tasks you performed this week will need continuation, which will be closing and which new ones will be started.

An example of such a section would be:

Next week
=========
* [HPC-123] Run validation on the new OS
* [HPC-234] Finish SVE work, submit a review
* [HPC-345] Hopefully merge the patch

The most important is: keep it simple, keep it short.

Problems and blockages

If you had any major blocking issues, make sure you mention them in here. This section normally doesn't appear on the reviews, as we keep them for special occurrences that not always happen.

For example:

Problems
========
* Lab outages meant OS upgrade could only happen on the last day

Usually, those problems should be report only, as this is not meant as a way to make people aware of the blockages. Ie. they should be fixed straight away with the right people as soon as possible, and only mentioned in this report as an explanation why something you planned to do in the previous week hasn't been done.

However, plans not always work as weeks pass, and it's ok to plan one thing on the previous week and do something different this one. For that reason, you don'y have to explain every plan that didn't work in this section, only the major and uncommon occurrences.


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.

But for that to work, the right cards need to be updated as you progress, with comments and changes to the workflow (status, priority, sub-tasks). If engineers don't update the cards, tech leads and project managers have no way to know what has been done.










  • No labels