Posted on by Zion Ng

Guidelines to protect developer time for meetings and sprints

Just came up with some guidelines which I feel would help in protecting developer time with regards to meetings and sprints, mainly by putting in some kind of structure. Disclaimer: These guidelines may not be applicable to everyone or every company 😛

Do read Paul Graham’s article on Maker’s Schedule, Managers Schedule which clearly explains how and why meetings can heavily disrupt a developer’s work. To take a call or attend a meeting, developers have to drop everything that they are doing and will not be able to do anything else during the meeting cos well, they have to pay attention and participate in it. The worst part is getting back to programming after the meeting – try out the memory exercise in my earlier blog post, Understanding the Programmer’s Schedule 🙂

[MEETINGS / CALLS]

  1. All meetings involving one or more developers should be kept to Mondays and Fridays. If a public holiday falls on Monday or Friday, the meeting may be rescheduled to the nearest weekday. This gives developers at least 3 days of protected time per week to work on their tasks. This does not apply to handovers and ad hoc company-wide meetings.
  2. The purpose and agenda for each meeting should be shared before the meeting, as early as possible, especially if preparation is required. The purpose must be clearly stated in the calendar invite for the meeting. All items on the meeting agenda should be actionable, i.e. result in an action either during the meeting or after it. The action must have practical value, e.g. make a decision, formulate a plan, allocate tasks.
  3. Dissemination of information, asking for data/analysis/opinions and seeking to understand products/systems/workflow should be done outside meetings, via emails or messages.

[SPRINTS]

  1. The duration of each sprint is 2 weeks. A work week consists of 5 days. Each work day consists of 8 hours. A sprint typically starts on a Monday and ends on the Friday of the following week.
  2. Each sprint should start with the sprint planning, preferably in the morning on the Monday of the 1st week, and end with a retrospective, preferably in the afternoon on the Friday of the 2nd week. If a public holiday falls on these days, the meeting may be rescheduled to the nearest weekday.
  3. Each sprint should have a main focus. Each developer should know what they should be focusing on in the sprint. Developer time can be classified into 5 categories (short names with different starting letters for quicker typing and auto-completion in time tracking):

    • Admin: Meetings, HR, interviews, answer questions.
    • Coding: Work on a repository, e.g. write code, documentation, deployment of new release.
    • Debug: Troubleshoot production issues, fix demo pages for clients.
    • Ops: Infrastructure, e.g. AWS, configure servers/CDN, modify database, renew SSL certificates.
    • Review: Look at others’ code, e.g. merge pull requests, understand vendor API, tech research.
  4. The Management/Business/Product team and tech lead should meet at least a day before the sprint planning, so that the tech lead can plan out the focus and tasks for the upcoming sprint. The Pólya-Kipling Method can be used for formulating the tasks and their requirements.
  5. In the context of JIRA and using The Chronicles of Narnia as an analogy:

    • Epic: A large body of work consisting of stories focusing on the same goal, e.g. a set of features to support a new client. An epic can last a few sprints. Example in analogy: Book Five (chronological order) – The Voyage of the Dawn Treader.
    • Story: A feature consisting of tasks for different components and likely multiple developers, e.g. work needed on database, backend API and frontend UI in order for the feature to be implemented. A story typically lasts only a sprint. Example in analogy: Chapter Six of Book Five – The Adventures of Eustace.
    • Task: A piece of work for a single component and developer, e.g. add new endpoint in backend API to support feature. Example in analogy: The transformation of Eustace in Chapter Six of Book Five.
    • Component: Typically corresponds to a repository, e.g. backend API. Example in analogy: Eustace.

As with all guidelines, refining and customisation will be needed as time goes by. For that, I’ll recommend sticking to the KISS principle (Keep It Simple, Stupid) and trying out the KISS process (what to Keep, what to Improve, what to Start, what to Stop) – ad huc!

[UPDATE 28 FEB 2022]

Additional Readings: