At Linaro, one way or another, we do a weekly report cycle to our groups, members and Linaro.
...
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 tasksprojects, 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.
...