Secret ingredients to quality software

SSW Foursquare

Rules to Better Inbox Management - 11 Rules

According to Statista, 269 billion emails were sent per day in 2017. That’s a lot of emails, and they can pile up fast - which is why it’s so important to keep your inbox under control. Emails are legal documents and should be treated with the same care as any other correspondence with clients or employees. You should endeavour to keep your inbox as a to-do list only and know how to file or delete emails as necessary so that your inbox reflects an accurate record of requests, conversations, and decisions.

Just as...

rules to better inbox management
Figure: Don't let your inbox become a vortex of doom - keep it organised!

  1. Do you clean your inbox per topics?

    Your inbox should be a task list and should be kept clean. When cleaning up their inbox people tend to go from top to bottom. A better way to do it is to search for a specific topic and clean up all related emails .

    clean inbox by topic outlook search
    Figure: Good example - Search for "SugarLearning", reply 'done' to all emails and delete them

  2. If someone asks you to perform a task by email, don't reply "OK, I will do that" or fail to reply at all. Instead, do the task and reply "Done" when the task has been completed, and then delete the email. This way the person requesting the task knows that it has been done, and doesn't waste time following you up.

    Read "Definition of Done" for more information about the steps that need to be finished before replying to a done email.

    Only say "Done" when the work is completed.

    • If you have added the email to your backlog or to-do list, then say "Added to backlog – URL is XXX". You should still reply "Done" when you complete the task.
    • For tasks that will take time to be completely done (E.g. Producing a long video), you may send a "work in progress" email. This way you avoid giving the perception that no action was in relation to the task. You should still reply "Done" when you complete the task.

    Alternatives to classic "Done" emails

    • If the task is already done, then reply "Already done - the reason is XXX"
    • If you don't agree with the task or are unable to complete the task, reply "Not done - the reason is XXX"
    • If there are multiple tasks (some "Done" and some "Not Done"), reply to each item individually "Done" or "Not Done"
    • If the task can't be 100% completed at the time, you may reply "Partially done - the reason is XXX"
    • If you have already sent a "Done", then the client asks you to undo the change, reply "Undone"

    Figure: Good Example - "Not Done" email

    Tip 1: Say "Done" first

    For clarity, "Done" (or "Not done" / "Already Done" / "Partially Done") should be the first word(s) so the reader knows the status straight away.

    Tip 2: Provide details in your "Done"

    In any reply, include relevant information, such as URLs, screenshots, and pieces of code/text that have been updated. This allows others to check what was done straight away.

    Tip 3: Replying "Done" to multiple tasks

    It is important that you clearly reply to each of the multiple tasks.

    Figure: Original email with the client request

    Figure: Bad Example – It is not clear which tasks have been done and which haven’t

    Figure: Bad Example – It is clear which tasks have been done, however, replying inline should be avoided as it messes up the history

    Figure: Good Example – It is very clear which tasks have been done and which haven’t. Quoting the original task is only necessary when some tasks are done and some are not see Do you use indentation for readability?


    What do you do with the "Not Done" tasks?

    If there are multiple items of work in an email and you can't do them all at once, reply to each item individually ("Done" and "Not Done"). With the "Not Dones" you should add a plan to action: a. Put yourself in the "To:" if you are going to do the remaining items later. b. Add another person if you are reassigning. c. Give a reason if it won't be done.

    Figure: Good example – If multiple tasks are 'done', then only the URL is needed. This is clear that all tasks have been done and they can read the history of the requests below.

    Tip 4: Replying "Done" to huge tasks

    Ideally, all PBI's should be done in less than 2 days. If you are given a task that is going to take more time than that, then split it by following breaking up monster tasks.

    Tip 5: Don't consolidate emails

    If you get multiple emails or tasks, don't consolidate them. Reply to each email individually as you go. This way the person requesting the work hasn't lost the email history and can understand what the work is done relates to. It also means that testing and/or feedback can come in as soon as possible after the 1st completed task.

    Tip 6: Delete "Done" emails - Aim for 0 inbox

    There is no point in keeping emails that just clutter your inbox. You don't need to keep the original email because after you have replied "Done", there is a copy in "Sent Items". If you must keep an email, then move to your "Saved Items" folder.

    Tip 7: When appropriate, use text instead of images

    Figure: Good example - This "Done" uses text instead of an image so it is easier to search; to copy and paste; and to reply with a modification

    Tip 8: Handle an email once

    Follow a tip from Adam Cogan:

    During my accounting days we had large physical in-trays and you were always picking up papers, looking at them, deciding it’s ‘too hard to do right now’, and then picking up another piece of paper... I learnt that a sign of an efficient person is that they handle a piece of paper once.

    Likewise, when you get an email - don't just open it, have a quick look and close it with the idea that you will go back to it later. Read it, make a decision and do the action. Delete as many emails as you can on the first go. In the same vein, when you complete all tasks in an email, delete everything in that thread.

    Tip 9: Consider alternatives in a team environment

    In a development team environment, it is better to move emails to tracking systems. E.g.:

    1. Azure DevOps Work Items
    2. GitHub

    Tip 10: Include a video when appropriate

    See how to record a quick and dirty "Done Video".

    Tip 11: Remember to thank people - don't be too brief and icy

    When replying 'Done' to a bug or issue someone reported, remember to thank the person for taking the time to send it. A short "Thank you for reporting this" helps to make your 'Done' warmer.

  3. This rule is a variation of the popular rule Do you send "As Per Our Conversation" emails?

    The most dangerous time in a task's life cycle is in a handover. This is the most likely time for a misunderstanding to occur leading to a task getting lost and not being completed.

    Always make sure you clearly reallocate a task with an email to the person who will complete the task like the good example below:

    Figure: Bad example - task not clearly reallocated

    Figure: Good Example - Clear reassignment from Andy to Sergei

    If you need to hand over an entire project there are more details here: Do you know how to hand over a project?

  4. If you are unclear use IM to ask, but remember the golden rule is to not send tasks on Teams.

    It is recommended to keep track of active project backlogs on the company intranet, while also including the Product Owner and Tech Lead contact information, coupled with a link to the Teams channel of that project.

    When reporting bugs and giving product feedback, it is essential that you are as descriptive as possible. This will save both you and the developer time and frustration in the long run.

    report bugs and suggestions
    Figure: Making the Product Backlog the main source of tasks

    Tip 1: Draft your bug with enough details

    Make sure you always explain and give as many details as you can of how you got an error or a bad experience. Detailed and useful descriptions can make finding the solution quicker and easier. The goal is to include enough details so the developer can focus on the development work more rather than trying to figure out what the feature requirements or bugs are. 

    See rules on Do you have a clear definition of a bug?

    External source: How to produce a good bug report

    Figure: Bad Example - This email isn't going to help the developer much - it is vague, has no screen capture or other details to help reproducing the error

    Figure: Good Example - This email includes the product name and version, the category of the issue (BUG), a screen capture, and informs the user's system

    When possible, a great template to follow is the Functional Bug template from the ASP.NET open-source project. Spending time to provide as much detail as possible, by ensuring you have the 3 critical components:

    • Steps to reproduce,
    • Expected outcome, and
    • Actual outcome

    Figure: Bad example - Lack of details

    Figure: Good example - We can easily identify more the one way to improve the UX and there's a clear suggestion to action

    Better than a good textual description of a bug report is a screen recording. This should be followed for a more detailed report. Use Snagit or Camtasia to record your screen.

    Figure: Good example - Recording bug reports in a video can make the issue clearer to see

    Tip 2: Draft your suggestion with the complaint and what you expect to see

    Define all the requirements as per Do your User Stories include Acceptance Criteria?

    Better than a good textual description of a suggestion request is a screen recording. This should be followed for a more detailed report. Use Snagit or Camtasia to record your screen.

    Figure: Good example - Giving suggestion requests via video

    Tip 3: Should you send this to the Product Owner or the Tech Lead?

    It depends on the team, but often the Product Owner is busy. If you know the Tech Lead and your suggestion is obviously a good one, then you should email the Tech Leader and Cc the Product Owner. The Product Owner can always reply if they don’t like the suggestion.

    For a bug email:
      To: Tech Lead
      Cc: Product Owner
      Subject: Bug - xxx

    For a new feature email:
      To: Tech Lead
      Cc: Product Owner
      Subject: Suggestion - xxx

    Tip 4: Should you email or put it in the backlog?

    Always go for backlog if you have access to a backlog management system otherwise email relevant people. You may have a group email such as, You would only Cc this email when a greater visibility is required.

    Tip 5: Do you make it easy to find all the backlog in your company?

    do you know how to report bugs and give suggestions
    Figure: An intranet page with links to projects’ backlog to make it easy for everyone to find. Note some projects have more than 1 backlog.

    Tip 6: Make sure when using backlog, the Product Owner will still get an email

    Create an Issue/PBI and @mention relevant people (GitHub and Azure DevOps will generate a nicely formatted email)

    See rules on Do you know when you use @ mentions in a PBI?

    Tip 7: Separate PBIs

    If they are all related to one area, then you could consider put them together, otherwise don’t bunch them up.

    See rules on Do you send tasks one email at a time?

    Tip 8: Use emojis and prefixes for PBI/Issues titles, or email subjects

    When you create a bug/suggestion to a backlog, it's a good idea to add emoji in the title. Not only does it look nicer, but people can look at the item and take in the necessary information quickly.

    This means that anyone looking at the backlog can glean its nature at a glance, rather than having to read each item to know what category it is (5 bugs, 2 features, etc). Examples:

    • 🐛 Bug - Calendar is not showing on iOS devices
    • ✨ Feature - Add 'Back to menu' item to top navigation

    Check out the rule on Do you know which emojis to use in Scrum?

    Tip: GitHub Issue Templates can help you with that.

  5. OK - so now you've got your important emails identified, don't let them get lost in the quagmire. If you use Outlook make use of its inbuilt functionality. Always sort your emails by the Received, but add a secondary sort by "Important". This way your important emails always stay at the top to haunt you until they are done.

    Figure: Good Example - Sorted by Important and Received Date

    The Red Exclamation Mark is a good start, but the Blue Arrow keeps getting my attention.

    Use sort by importance to sort the items with the blue arrow to the bottom.

  6. Do you always keep your sent items?

    You should never ever delete your sent items. This will in most cases be the only record you have of the emails you have sent to customers and clients. If you ever need to find some correspondence (and believe me you will) then you will be very thankful you got into this habit!

  7. You may be involved in different tasks simultaneously every day. The best way to organize your tasks and follow each task individually is grouping your emails by conversation. By default, Outlook groups the emails by Date.

    Figure: Bad example. Email messages are grouped by Date

    Figure: Good example. Email messages are grouped by Conversation

    Follow these steps to group by conversation:

    1. Open Outlook and select the Mail View.
    2. Right-click any column and choose the "Customize Current View..." option.
    3. Select the "Group by..." option as displayed in the image.

    Figure: Steps to group by conversation field

    1. Select the "Conversation" field from the list. (Leave empty the remaining groups)

    VIDEO - Top 10+ Rules to Better Email Communication with Ulysses Maclaren

  8. Do you know how to handle duplicate requests?

    Sometimes you get the same task from 2 different people. Sometimes even the same person sends over-lapping emails. Sometimes you find duplicated PBIs.

    Whether you keep a backlog or are just using your email inbox as a to-do list, you have a choice to make:

    A: Get rid of the duplicates and only keep one (you need to spend time informing everyone about the merge)

    B: Recommended - Keep them all and when you do it, reply to all the emails with your ‘Done’ OR close each of the PBIs. (Of course it is a good idea to relate those tasks by adding links or the email subjects)

    Figure: Bad example – This email will never get a ‘done’ when completed

    Figure: Good example – Both emails got a ‘done’ reply and were referenced to each other

  9. There is a hidden cost that every task or email in your inbox adds that is easy to miss, and that is that every time you scan over an item and decide not to do it, you are really just kicking the can down the road, and your future self will have to later scan that item again, and possibly again decide that it’s not worth doing yet, and so kick it further down the road.

    This tiny cost once multiplied multiple times per task, and considering how many small (<5 minutes) style tasks we all get in a given day, can end up taking up a sizable portion of your effective time while at work.

    To combat this, if you ever receive a task that would take 5 minutes or less to complete, do it immediately, replydone if necessary, and then delete it.

    Another way to implement this principle to save yourself the cognitive load of re-reading emails is to forward emails to For example, if you know you won’t be able to work on a particular task for at least 2 weeks because of a dependency, forward the email to, and it will reappear in your inbox at the time you can actually do something about it.

  10. There are many types of emails which you receive but will never actually reply to. For example, a client may email "Sounds great - please go ahead." These kinds of emails should be kept as a reference for the future.

    Emails that came into your mailbox should not be left in your Inbox. The aim is to read, action (if needed) and delete. You should be trying to get your Inbox down to 0 items.

    So what's left in your 'Inbox' should only be 'To Do' items. Sure you might want to add subfolders to group related projects etc. but these subfolders should also contain items 'To Do'. Some people leave emails in their Inbox, for later reference only. We believe this is not a good idea, and you should create 2 folders outside your Inbox called 'Saved Items' and 'Saved Personal Items' for such emails.

    Figure: Good Example - Save important reference items in a separate folder

    Microsoft Outlook provides you with 4 main folders: 'Draft', 'Inbox', 'Outbox' and 'Send Items'. But we believe they are missing 2 additional folders: 'Saved Items' and 'Saved Personal Items'. You can use these two folders to keep your work-related or personal emails that you wanted to keep.

    You can create these two folders next to the Inbox and move the emails there.

  11. Throughout your years of surfing the net, you're sure to have subscribed to some newsletters that may have interested you at the time. As your interests and preferences change, you will find that you're still on many different lists.

    Instead of deleting the email from your Inbox and thinking that the problem has been solved, you should take the necessary steps to unsubscribe from the list so that you will never get bothered again.

We open source. Powered by GitHub