Daily Stand-Up

The daily stand-up meeting is a daily morning meeting to help steer the teams daily and weekly goals.

The meeting should last no more than 15 minutes.

Before the meeting
The PM must have updated UpBase to match the planned daily and weekly schedule taking into consideration any changes that have arisen since the last meeting
During the meeting
A screenshare of the support desk, Monday.com, GitHub Project Board(s) and any other related systems must be on screen

Do you NEED a Stand-up?
If a business-critical issue is impacting the regular stand-up then consider delaying or even cancelling the stand-up. Also if it genuinely feels like the stand-up can be skipped then cancel it and provide information in Slack to steer any important tasks.

During the Meeting

The meeting doesn’t require any introductions or pleasantries, as soon as everyone is logged in then we kick things off:

Freshdesk / Support desk review:

Open Default View: https://makedo.freshdesk.com/a/dashboard/default
Ticket Rename: Make sure to rename any ticket subjects to match the actual issue and remove any email-based suffixes such as ‘RE:’ or ‘FW’
Review On-Call: The on-call Engineer and PM review any new items that came in out of hours
24 hour Ticket Review: A review of any tickets from yesterday which were not addressed or remain in an unresolved or unclear state Use the ‘Tickets: 24 hours’ filter in Freshdesk for this
Lingering Tickets: Review any ‘lingering’ support items that require chasing or closing Use the ‘Tickets: Lingering’ filter in Freshdesk for this
Triage to GitHub or Upbase: During the review if any support desk items require triage they would also be added to both GitHub and / or UpBase but only if this is relevant, please note this is a edge case and is not the norm
SPAM Folder: Check SPAM for any tickets that may have been added there
Slack 'excom' Channel Check: Ensure any messages from clients are picked up from Slack and converted into issues or tickets if needed (the Slack to Freshdesk extension can be used for this).

For support tickets that are ‘stuck’ in Code Review or QA please note that these are the responsibility of the REQUESTOR not the REVIEWER to be complete and that, the REQUESTOR must then chase the REVIEWER to complete the work

GitHub & Code Review Review

Start with a quick and ‘holistic’ view of the ‘Team Dashboard’ https://github.com/orgs/mkdo/projects/11/views/1

Next, check all items in active 'Code Review' https://github.com/orgs/mkdo/projects/11/views/38

Make close attention to the Code Review, QA and Client Review columns to make sure that these are all properly assigned and can be moved forward
Finally review the In Progress column and clarify that team members are using the board correctly and have their active work in the correct place

Remember: At no point should the board become the sole focus of standup and any distractions issues or problems should be taken care of after the call has ended.

Harvest Review

Review the Team View in Harvest to validate time has been tracked for the previous day or week

Note: It is especially important to review Harvest near the end-of-the month as client reports are generated in the first week of the following month and if data is missing at this point hours will be missed.

End Meeting and Discuss Blockers or Issues

Blockers can be addressed immediately if the solution is simple (IE ‘I will talk to the client’), however if they need more in-depth discussion an agreement for the parties involved to have a meeting outside of this one can be arranged.

Branching Off Specific Meetings

At no point should a technical solution be discussed in the standup. Any specific project work or other discussions should be taken into a breakout call or scheduled for later that day.