...
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.
Rationale
The weekly email was redundant and boring, but it had all the information we needed in a condensed format. So, to completely deprecate it, we need to find similar solutions in Jira that can replace every "feature" of the emails.
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.
Three Blocks
Jira + wort time
Since we're updating Jira cards, we don't need to reference the cards anywhere. Just adding comments to the cards would be enough.
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.
Plans for next week
Tasks that are "Open" 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.
This is essentially the "next week" plan. Given the vague nature of the original plan, and how it could be overruled but new tasks, there's no difference at all.
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, the ones that would be reported on the weekly email, after you have reported and followed up in the right channels, should be moved to the "Blocked" column.
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.
So, if you have a blocked task, but you can do other tasks while you wait for that one task to be unblocked, do not move them to the "Blocked" column.
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.