What is the Daily Synchro
The Daily Synchro is a short, summary report of your daily deliverable(s) and your planned activity for the next day. The Daily Synchro is written daily.
The Daily Synchro's content is very similar to what you would say during a daily stand-up meeting. In fact, the Daily Synchro originated out of a need to avoid daily stand up meetings and replace them, for remote or WFH teams, by an online equivalent. However, while stand-up meetings are primarily for informing and communicating with other team members, the Daily Synchro is primarily for the benefit of the customer.
If your team has a daily stand-up meeting, a daily synchro may not be necessary.
What is it for
The purpose of the Daily Synchro is to keep the product owner informed of your progress:
- Inform them of your daily deliverable so that they can verify them
- Inform them of your intended focus for the next day, so that they can, if necessary, change their priorities and direct you to focus on something else
- Ask them for clarifications about their requirements
- Inform them of any technical (or functional) difficulties that you may have encountered
Note that the purpose of the Daily Synchro is not to provide minute-by-minute accounting of your day’s 8 hours of work. The Daily Synchro should be short and to the point.
When should I write my Daily Synchro
You should write a Daily Synchro every (working) day at 2pm.
As its name implies, the Daily Synchro is a daily report and therefore must be produced every day. Since it includes your daily deliverable(s), you should write it once your daily deliverable(s) are completed. As per our best practices for the daily deliverable, this must be at 2pm rather than at the end of the day.
For some projects, the lead developer will collate the individual Daily Synchros from each developer and write a team Daily Synchro for the customer. Delaying your Daily Synchro will simply create unacceptable pressure on the team leader.
Where should I write my Daily Synchro
This may vary from project to project. Generally, you should write your Daily Synchro in the designated Slack channel. This may be a dedicated “Daily Synchro” channel in the customer’s Slack group, or it may be in the project channel in the Dzango Slack group.
What is the format of the Daily Synchro
Keep the Daily Synchro short and to the point. Avoid unnecessary words (eg "Added ..." instead of "I have added..."). You can follow the same format as for conventional commit messages.
Avoid unnecessary sentences such as "please review and comment", unless you want to point the customer's attention to a specific aspect of the deliverable.
Avoid sentences like "I will finish this tomorrow". This is implied (otherwise you should report instead that this ticket will take you longer than expected, that therefore you do NOT expect to finish this tomorrow, and that you ask whether this ticket's priority should be reconsidered).
Recommended date format: DDDD, dd MMMM (eg Wednesday, 19 October).
The date format may vary according to the customer's preferences. Please follow a consistent format as per previous reports.
List your daily deliverable(s) here.
Only qualified deliverables should be listed in this section. If it's not a deliverable, use another section or report it when it becomes one.
For each deliverable, provide all the relevant information for the stakeholders to verify it. This may vary according to the deliverable, but could include some or all of the following:
- Url to relevant page in staging server
- Instructions on how to verify the feature or bug fix
- Appropriate credentials if login is required as a specific user
- Link to ADR or ticket analysis
- Link to ticket
- Videos or screenshots
* For admin, made the activity page mobile responsive * For admin, moved "Download all activity" button above table [link to page on staging server] * ADR: Which css scoping to use [link to ADR] * Finished analysis for the implementation of the print layout of the users table. [link to ticket] * Added unit test for the case when getActivities gets future date. [link to CI running unit tests on staging image]
Work in progress
In this section, list anything that is available for stakeholders to see that does not qualify as a deliverable.
This could include a feature or bug that that has not yet been fully implemented or not fully tested, but is sufficiently advanced that the customer can start validating it without wasting their time.
This should be reported using the same format as a deliverable, but with additional indications of what has been implemented and/or tested, and/or what has NOT been implemented or tested. Please avoid vague expressions like "Not fully tested" in favour of, say, "Not tested on Safari".
* For admin, the activity list is paginated. Not fully tested in Safari and edge browsers. [link to relevant page on staging] * Found issue on Firefox where user can't click on the next button * Tested all known cases on Safari and it worked, but not on other browsers
Use this section to:
- Indicate what your next (tomorrow's) deliverable will be. A simple description (one line) should be enough. Include a link to the relevant ticket.
- Ask questions or request clarification of the specs.
- Notify of an ongoing or new technical issue that may impact your ability to resolve the ticket you are working on
* Make the basic printing take our layout. * ADR (WIP): How many layers of architecture to put on excel export [link to ADR]
Use this section to request clarification about priorities, or anything not directly related to a specific ticket.
Anything useful to the customer that does not fit in any of the above sections:
- If working in pairs, who is your pair partner
- Leave of absence
* I noticed an issue with open activity in new tab button [link to ticket]. Is this high priority? this may take some time, should we skip this for this week? * Pair programming with @colleague * Tomorrow I will be on leave. * I got stuck on a ticket [link to ticket], which i have paused. Since this was low priority anyway, I will continue it next week only