SSW Foursquare

Rules to Better Communication - 22 Rules

What we've got here is failure to communicate!
– Cool Hand Luke

So many problems in business come down to a lack of clear and effective communication. Here is a series of communication rules that should give you an edge.

  1. Do you follow up tasks effectively?

    Sometimes you can't complete a task right away or anytime soon. People might just say: "I can't do it this week, but I should have it done by the end of next week".

    Another scenario is when the task should be done or will expire after a period of time. For example "Send Google Analytics data after a month" or "Remove course banner once the course is completed".

    If you leave it like that there is a high chance it gets forgotten as remembering tasks is a highly unreliable method.

    Efficient people don't rely on their memory and instead, use some way to make sure they don't forget to do that task. Common ways are to make a note in a paper diary or stick a post-it note to a screen, but there are better ways.

    adobe firefly screen with sticky notes
    Figure: Bad example - Oldies use yellow sticky notes

    To ensure you follow up on tasks, it is important to set up an action point so it can be forgotten until later. That frees up cognitive space so you can focus on something else but still be certain it will be actioned later.

    The Tools

    There are some okay tools like delayed send and follow up flags... but the our Top 10 gold standard tools are:

    1. Email - Followupthen.com
    2. Outlook | Schedule Send
    3. Outlook | Follow Up Flag
    4. Microsoft Todo
    5. Microsoft Teams | Schedule Send
    6. Microsoft Teams | Remind App
    7. Microsoft Teams | Hiding Chats
    8. Phone | Reminders
    9. Calendar | Meetings
    10. Sprints | Creating a PBI

    1. Email - followupthen.com

    FollowUpThen is the best tool to use when a task arrives in your inbox that you want to make sure gets completed. It does all the administrative work for you.

    Simply BCC or email {{ TIME }}@followupthen.com and it will send you an email when that time expires, reminding you to follow up with another email. If you BCC, you can include '(Bcc'ing {{ TIME }}@followupthen)' at the top so other email recipients know you will get the reminder.

    Figure: Good example - Use 1week@followupthen.com to be reminded of this email in one week

    Note: This email thread is sent to a 3rd party, so strip out any confidential information before using this tool.

    2. Outlook | Schedule Send

    Schedule Send is an alternative to followupthen that involves scheduling emails to be sent later. It is integrated directly into outlook but Outlook must be open for it to send, and if someone writes back before the scheduled time then it could become irrelevant.

    Video: Delayed Emails as Reminders in Microsoft Outlook (4 min)

    To use it:

    Write yourself an email in Outlook.
    Before pressing send, click Pull Down Arrow | Schedule Send, and then specify on the calendar when you want to send the email.

    The email will sit in your outbox until the required time, when it will be sent to whoever you specified (you in this case).
    When you receive it in your inbox, action the task.

    schedule send tab
    Figure: Good example - Schedule send option in Outlook
    schedule send calendar
    Figure: Good example - Pick date and time for delivery

    3. Outlook | Follow Up flag

    Follow Up Flags are a third alternative for email reminders. It is also integrated with Outlook but it's main problem is it just gives a notification instead of an email to be actioned. That means it is transitory and could be missed. This can be solved if you use the Microsoft Todo app in conjuction with Outlook. We will discuss this in the next section.

    To use it:

    1. Click the Follow Up button

    followup1
    Figure: Set a follow-up date

    1. Select an appropriate date from the drop-down or choose Custom to add additional reminders

    followup2
    Figure: Add an additional reminder to follow up

    You can even set a custom reminder for the recipient :)

    1. Outlook shows an info tip with the exact follow-up date you chose
    2. A To-Do item is also added to your Outlook To-Do list

      Note: To-Do list can be found in the Tasks pane.

    3. On the due date you will receive a Reminder popup from Outlook
    4. If you chose to add a custom reminder you will also receive a Reminder popup from Outlook

    followup3
    Figure: OK example - Using Follow Up Flags to set email reminders

    4. Microsoft Todo

    This app works in tandem with Outlook to create todo lists and tasks. You can set reminders for daily tasks and even have flagged emails show up in you list as a work item.

    microsoft todo summary page
    Figure: See your whole day of tasks on a single window including flagged emails

    5. Microsoft Teams | Schedule Send

    Here is a practical and useful feature in Teams. With Schedule send you can schedule all your important messages in advance.

    • Right click the send button to schedule all the important messages in advance.

      Figure: Right click | schedule send

    6. Microsoft Teams | Remind App

    Remind yourself or your team members of important meetings, to-do items or even birthdays. Set personal reminders, group chat reminders, or channel reminders. You can even set recurring reminders (e.g. a team meeting every Monday at 9am)!

    Get the app.

    Figure: Remind App in Teams

    7. Microsoft Teams | Hiding Chats

    Alternatively, to keep track of outstanding queries, after answering a question in chat, Right Click | Hide the conversation and now your Teams chats are like a todo list.

    8. Phone | Reminders

    Phone reminders made via Siri or Google Assistant are awesome when there are things that should be actioned immediately after receiving the reminder.

    For example, if Jane knows she wants to film a video at 8am tomorrow then she might ask Siri to remind her at 7:55am. Then when she gets the reminder she knows to film the video right then.

    iphone reminder
    Figure: Good example - Phone reminders are great for tasks that need to be actioned immediately

    9. Calendar | Meetings

    If more than one person needs to be coordinated, then meetings are the best way to go about it.

    Meetings draw everyone's attention and block out their calendar.

    If someone doesn't show up to the meeting, just call them in. If you still don't get a response and they are critical to the meeting then re-schedule it for later to make sure there is a new action point.

    Also make sure to send an email with an action point at the end of the meeting, you never want to end a meeting without action points. You can even use followupthen to make sure you follow up on it!

    calendarfollowup
    Figure: Good example - Meetings are the best way to follow up on tasks that require multiple people's attention

    10. Sprints | Creating a PBI or Task

    If working in an agile team it is important for everyone to have visibility of PBIs and tasks. So, if you know something needs to be actioned, then you should always create a PBI or task.

    Sprints also naturally act as a follow up since the tasks will be discussed in the Daily Scrum and Sprint meetings.

    pbifollowup
    Figure: Good example - Having a task or PBI in place makes sure a problem gets addressed

  2. Do you know the best tool for facilitating real-time collaboration?

    When collaborating within teams, the current process involves soliciting individual updates or feedback, with one team member responsible for manually compiling this information. Unfortunately, this method presents several challenges:

    • The need for manual compilation of feedback/updates
    • Time-consuming process
    • The individual providing the original feedback must verify it, as it has been consolidated into a single file
    • Any subsequent updates may necessitate the creation of a new version (v2) of the compiled file

    Fortunately, Microsoft Loop offers a solution by introducing interactive notes shared seamlessly across all Microsoft 365 products. This addresses the challenges by eliminating the need for manual compilation, streamlining the process, and ensuring that updates are instantly accessible to all stakeholders.

    onenote bad example
    Figure: Bad example - Creating Notes in Microsoft OneNote

    Manual Compilation - The need to manually gather and compile updates or feedback within OneNote
    Limited Real-time Collaboration - OneNote may not offer extensive real-time collaboration features, hindering simultaneous contributions
    Version Control Issues - Challenges in managing versions of a OneNote document, particularly when multiple edits are made concurrently
    Accessibility Challenges - Ensuring all team members have immediate access to the latest updates in a cohesive and organized manner can be cumbersome in OneNote

    microsoft loop good example
    Figure: Good example - Using Microsoft Loop for interactive update within Teams chat)

    Automated Compilation - Microsoft Loop automates the compilation of updates and feedback, eliminating the need for manual efforts
    Real-time Collaboration - Loop facilitates seamless real-time collaboration, allowing team members to contribute simultaneously and see updates instantly
    Versionless Updates - With Microsoft Loop, there's no need to create new versions for subsequent updates, ensuring a single, dynamic source of information ✅ Integrated Accessibility - Loop's integration across Microsoft 365 products ensures that updates are easily accessible and shared across the entire ecosystem, enhancing collaboration efficiency
    Dynamic and Visual Collaboration - Microsoft Loop offers a visually appealing and dynamic collaboration environment, allowing for the incorporation of rich multimedia elements, interactive charts, and engaging content
    Explore the Microsoft Loop App:

  3. Do you cater to your audience?

    Often when you are talking with others, it is easy to forget they have a different background and experience to you. Then, once you start explaining something to them, they easily become lost. So, it is crucial to think about your audience before talking.

    Some examples of the differences in what different people on the team might care about include:

    • Product Owner - May not care about all the technical details, but cares a lot about PBI progress, roadblocks, etc.
    • Developer – Cares a lot about technical details but may not be as concerned with the business side of things
    • Designer – Cares a lot about the UI and user experience but may not be as interested in technical details

    Scenario - Adding a new field to an app

    Let's say you've been asked to add a new field "Customer Name" to the Northwind app Projects page. You are making progress and it's almost finished but there are a few important points.

    • Business Impact - The PBI effort is 4 story points (~8 hours) and you've already almost used up your time, but you think it will take roughly 4 more hours to finish
    • Technical - There is a problem because the CustomerId is being stored in the Projects table without any relationship to the Customers table
    • UX - You aren't sure about where to put the field on the page

    First, let's see what a bad example of explaining this PBI looks like:

    Hey,

    I’m almost done with this PBI but I'm having trouble adding the "Customer Name" field to the Projects page because there is no relationship set up in the database.

    I'm also not sure about where to put the new field on the Projects page... I'm thinking of putting it in the top left, but am open to opinions.

    Overall, I think the PBI is going to take a few more hours than we thought due to these roadblocks.

    Figure: Bad example - The message's audience is not targeted, making it hard for others to decipher

    So, how would you explain this scenario to different people?

    Explaining to the Product Owner

    They're probably not as concerned about the UX problem or the technical issues, so you want to emphasize the business value and any roadblocks.

    It's also a good idea to give them the option to hear more technical details incase they want to learn more.

    Hey,

    I'm almost done with this PBI but it's going to take a few hours more than we estimated because I've run into some roadblocks.

    I need to have a chat with the Design team about how to best handle the UX and with the development team about how to resolve a technical issue.

    Once I've done that then it should be ready to deploy to dev :)

    Would you like to know more technical details, or should I get cracking?

    Figure: Good example - Targeting the message towards the Product Owner

    Explaining to the Developer

    They're probably not as concerned about the UX problem or the business impact, so you want to emphasize the technical side so they can help you out.

    Hey,

    I'm having trouble adding the "Customer Name" field to the Projects page because there is no relationship set up in the database.

    Do you think I should add it?

    Figure: Good example - Targeting the message towards the Developer

    Explaining to the Designer

    They're probably not as concerned about the technical issue or the business impact, so you want to emphasize the UX problem so they can help you out.

    Hey,

    I'm adding a new field to the Projects page for customer name. I'm thinking of putting it in the top right.

    Do you think that is the right place?

    Figure: Good example - Targeting the message towards the Designer

    Taking it further #1 - Knowing individuals

    You can take this idea even further once you get to know specific people. Try to pick out the things you think they care about.

    For example, I might know that Jane...

    • Cares a lot about Employee Experience and Automation
    • Doesn't care about dressing well

    Or I might know that Bob...

    • Cares a lot about meeting deadlines
    • Doesn't care about budget

    Once you figure out each person's characteristics you can then target your messages even more for maximum effectiveness.

    Taking it further #2 - Reading the room

    One other thing to take into account is that what you say is only 1/2 of the journey to understanding. The other 1/2 is the recipient listening, so:

  4. Explaining - Do you zoom out then in?

    Explaining problems can be really hard. Often, when you are trying to talk with someone about them, they get lost and frustrated because they don't fully understand the context.

    That's why it is crucial to start at a fully zoomed out level and slowly zoom in with your audience.

    When trying to explain something, think about it in the context of 3 levels of zoom:

    • Macro Zoom - Context
    • Normal Zoom - Challenge
    • Micro Zoom - Core

    Each level provides a little bit more context so that the listener can understand the next level down and eventually reach the core question.

    Figure: Zoom and enhance!

    Scenario - Problems interacting with the database for a new view

    Let's take a look at an example of how these levels are applied practically.

    A developer has recently been asked to build a new table view. The view will show information about the work that consultants have done on client projects. The developer has run into a roadblock because they aren't really sure how best to get the data from the database. Specifically, they aren't sure what query to run or how to structure the classes in the code.

    What they shouldn't do is jump straight into the meat of the problem by saying something like:

    How should I structure a class for a table?

    Figure: Bad example - The listener has no idea what screen or problem is being talked about

    Macro Zoom - Context

    Explain the context first to give a big picture view of what’s being discussed.

    I am working on a table view in TimePro, which needs to display information about how many hours our consultants worked on each client project.

    Figure: Good example 1/3 - Now a baseline for what we are talking about has been established

    Normal Zoom - Challenge

    Next, zoom in a little to talk about your challenge with this task (why you’re having this conversation in the first place).

    The challenge I’m facing is finding a suitable way of getting the relevant data, because of the flexibility between which clients are selected and which consultants may be present.

    Figure: Good example 2/3 - This sentence helps the listener understand the specific difficulties being faced

    Micro Zoom - Core

    Now that the audience knows what you’re trying to achieve and the challenges, you can delve deep into the core question itself.

    I’m not sure how best to query the database efficiently, or how I should be structuring the DTO in a way that doesn’t duplicate information unnecessarily

    Figure: Good example 3/3 - A baseline context and the challenge have been established, so the listener can understand the original question


    You might be thinking this example is very specific to software developers... but you can really do it in any kind of role.

    Here are some other examples:

    Scenario - Editing a video

    Let's look at an example for a TV crew member.

    They are editing a video about zooming in and out. However, there is a problem because they have noticed that the wrong microphone was used, meaning the sound quality is bad. Now, they want to know if they need to re-record or if the stakeholder is happy with the audio as is.

    What they shouldn't do is jump in with the question about re-recording straight away.

    Should I re-record this video?

    Figure: Bad example - The context and challenge haven't been explained yet, making it confusing

    Instead they need to slowly zoom in by explaining the context, then the challenge, then the core question.

    I'm editing the video on zooming in and out.

    I've run into an issue because I've noticed it was recorded with the wrong microphone.

    I think the audio is good enough, are you happy for me to run with it or do you want me to re-record?

    Figure: Good example - The context was explained, then the challenge, then the core question

    Scenario - Ordering a pinball machine

    Let's take a look at an example for an admin.

    They have been asked to procure a pinball machine for the office. They've run into a roadblock because the model that they were asked to get is out of stock everywhere. Now, they want to find out if they should wait 2 months for stock to come back or order another one they found online.

    So, they should make sure they don't jump in with the first question about ordering a different model.

    Should I order this other pinball machine?

    Figure: Bad example - The context and challenge haven't been explained yet, making it confusing

    I'm ordering that pinball machine we talked about.

    Unfortunately, it's out of stock everywhere and won't be back in stock for 2 months.

    Should I order this other pinball machine instead?

    Figure: Good example - The context was explained, then the challenge, then the core question

    The outcome

    If you apply these techniques, your conversations are going to be:

    • More efficient
    • Happier
    • Stress-free
  5. Do you know when and how to ask for help?

    Ideally, you should point out any problems with a work item when you are first assigned it in Sprint Planning. However, sometimes you think a PBI will be fine, but then you run into blocking issues during the Sprint. In that case, you shouldn't wait until the next Sprint Planning because that is burnt time being blocked. So, you are forced to do some googling, and investigation on how to move forward. These moments can be stressful, especially for junior developers and the question arises... "When should I ask for help?"

    Asking for help should follow 4 phases:

    1. Determine if it's time to ask
    2. Do your due diligence
    3. Figure out who to ask
    4. Prepare to talk to a senior

    1 - Determine if it's time to ask

    As everyone's struggles are different and everyone's way of handling pressure differs, it's hard to provide a useful metric for when to ask for help. However, here are some useful guidelines:

    • Don't spend more than 1 hour blocked on a PBI before asking your team
    • Don't spend more than 1/2 the allocated time of a PBI blocked before asking for outside help

    If you've spent more time than that blocked and haven't spoken to anyone That is a problem!

    For example, if a task is 2 days long and you haven't been able to get anything done on the first day... You should be asking for help. If you aren't then that's a red flag.

    2 - Do your due diligence

    Before asking for help, ensure you've done your due diligence and exhausted your usual avenues for unblocking yourself. This concept is critical when trying to talk with senior developers because their time is valuable. You need to start your communication with a senior prepared and make it clear that you've tried to help yourself first. Often by doing this, you'll also resolve your own problem.

    Here are some things developers should do before asking for help:

    • Try Googling it
    • Check Stack Overflow
    • Read the documentation e.g. Microsoft Docs
    • Explore the code

      • Look at pages that do similar things
      • Put breakpoints and check the values to see if you can figure out little bits
      • Debug systematically by checking a tiny part, confirming your understanding, then moving to the next part
    • Try to resolve it yourself a few times
    • Explain the problem to yourself

    3 - Figure out who to ask

    Now that you are sure you need help, it is time to figure out who can help you.

    Your development team cares the most about your problem, and you want to bother those with the least valuable time first. So, follow the below process:

    1. Run your problem past someone at a similar level to you
    2. If they can't help you, move to the next level of seniority
    3. Repeat step 2 until there is no one with higher seniority in the team
    4. Call in outside help

    Tip: If you have no idea who to contact, ask your Scrum Master!

    4 - Prepare to talk to a senior

    If you still feel you're blocked, it's time to prepare to talk to a senior.

    Make sure your struggles are documented in a PBI including context, screenshots and what you have tried. Now, ideally you want to provide a recommended action before you call. Do your best to find one and then there are two paths:

    If you have a recommendation
    1. Document the recommendation in the PBI so that you can manage up when you call.
    2. Call and share screens showing the documented information.
    If you do not have a recommendation
    1. Document what you did to try and find a recommendation in the PBI.
    2. Call and share screens showing the documented information.

    That way, the senior doesn't need to interrogate you to figure out what you have tried already, and they can see you have made an attempt. If you can’t get hold of them, send a message with the prefix “⚠️ Blocked” to ensure the other person knows that you can’t proceed without them.


    Other tips

    • A Done Video can help you organize your thoughts and prepare to explain the issue
    • Bring your issue up in your Daily Scrum as a roadblock
  6. Do you document discoveries and decisions?

    Work items often have a great description and Acceptance Criteria. However, work can change quickly; sometimes, the justification for those changes ends up in emails or instant messages.

    If decisions and discoveries aren't in a central location, it can cause significant pain down the line. For example, if a new developer starts working on a work item, they might get halfway through the task only to find out their work has been wasted due to side conversations in emails. Therefore, when the requirements of a Work Item change or critical information is found, these details should be accessible to everyone on the Scrum team.

    That's why the discussion section of a work item rocks!

    Video: Documenting decisions and discoveries with Piers Sinclair (3 min)

    What should be documented?

    All important discoveries and decisions made around a Work Item should be recorded. If you think another Scrum team member would find the recorded information useful or you will need to recall it in the future, then document it.

    Some examples include:

    Discoveries

    • A developer finds a blocking issue hindering the Work Item's progress
    • A developer has investigated Application Insights, they can't see any errors, and they don't think there is a problem with the HTTP calls. So, Application Insights is no longer a priority for investigation
    • A tester notices a problem with a feature

    Decisions

    • The Product Owner has asked for changes to the functionality
    • A developer gets approval to implement a new UI design
    • A tester has tested and approved the feature in staging

    What about project-wide changes?

    If you're documenting something that affects the project at a high level, make sure to create an artifact for that in your project documentation and then link to it in the PBI as well.

    When should changes be documented?

    Ideally, you want to update an item as soon as a critical decision or discovery has been made. However, updating the Work Item at the following stages is particularly important.

    • Before a call
    • Before a Sprint Review
    • After a significant event
    • Before switching focus
    • Before going home

    Keeping Work Items as up-to-date as possible ensures that the information is recorded while fresh in your mind, isn't forgotten about and has a strong audit trail. It also keeps the people invested in the Work Item informed of progress.

    How do you document changes?

    Now, you might be wondering about the best approach for recording a change.

    Noting it down seems like a good idea, but the problem with that approach is that it quickly gets lost or forgotten about and isn't recorded in a regularly checked place.

    Sending an email is an okay approach, but the information will quickly be lost, buried under hundreds of other emails, unseen by anyone who might need to see it later on. Additionally, the audit trail is poor since there is no consistent thread.

    The best method is for developers to update the discussion thread of the Work Item they're working on. Then, if an email is really needed, send a link to the Work Item.

    Using the Work Item discussion provides several benefits to developers on the team, including:

    Providing one source of truth

    Work Item hand-off doesn't need to be an involved process

    Providing a history of the Work Item

    Easily accessible by anyone in the team

    Provides proof of approval

    RecordingInNotepad
    Figure: Bad example - Decision is recorded in notepad

    Figure: Bad example - Sending an email to confirm updates to the work item

    document discoveries good example
    Figure: Good example - Decision is documented in the work item

    Bad example Adding and Item to the backlog
    Figure: Bad example - Moving a PBI to the backlog without documenting the decision

    Good example Adding and Item to the backlog
    Figure: Good example - Moving a PBI to the backlog and documenting the decision

  7. Do you know how to define a PBI?

    It is very common that a developer looks at a PBI to work on, and finds out that it has limited or missing information. Usually, this is due to unclear requirements, ambiguous instructions or people simply don't understand the importance of getting the right information in the PBI.

    When that happens, it is crucial for the developer to raise their voice and gather enough information so it meets the Definition of Ready. Additionally, anyone working on the task who doesn't fully understand should raise the problem ASAP.

    Generally, there are a few pieces of information that every PBI should have:

    If the PBI is missing any of these things, make sure they are defined. Don't be afraid to push back, all developers should understand exactly what is expected.

    Remember, it is not your fault if there is missing information in a PBI, but it is if you allow that incomplete PBI into the Sprint.

    The Definition of Ready helps to enforce this, by formally documenting the requirements for acceptance from the team. So, make sure to refer to this document if there is any confusion about a PBI definition.

    Here are a few key checkpoints where these issues should be flagged:

    Ideally, you want to flag the missing information early, but it is better late than never.

    r1rmwbe9ak
    Bad example - The PBI has no information beyond a title

    xlwwtinlrk
    Good example - The PBI has a description, acceptance criteria, and more

  8. Do you know how to explain PBIs?

    Explaining work can be hard. When you are presenting in a Sprint Review, it is difficult to gauge exactly what information to give to the Product Owner and how to deliver it.

    As a developer, it might be super exciting to talk about all the technical details and start explaining those aspects. However, the Product Owner probably cares more about the business value. So when you are talking about the technical parts they may get lost or simply think you are wasting their time.

    Luckily, there are a few tips and tricks you can use to make sure you are ready to show the Product Owner your work:

    Video: Explaining a PBI to a Product Owner with Jake Bayliss (5 min)

    Ways to help the Product Owner

    • Give context - For them to understand the big picture first by zooming in then out and catering to your audience
    • Show and compare - For them to learn the differences between the old version and then the new version
    • Ask Questions - To resolve any confusion or gaps in knowledge that they have and confirm they understand you are about to move on to another topic

    You can also prepare better by:

    • Recording a Done Video
    • Practicing with a dry run

    This type of preparation can help you organize your thoughts and explain the issue.

  9. Do you use meaningful PBI titles?

    Product Backlog Items (PBIs) are the cornerstone of a well-oiled project. They track features, bugs, tasks, and much more. When a developer or Product Owner is looking through the backlog, it's important that - at a glance - they can read the titles of PBIs and have a decent understanding of them.

    So what separates a good PBI title from a bad one?

    Video: Do you use meaningful PBI titles? | Luke Cook | SSW Rules (5 min)

    Note: Usually, we use the term PBI to encompass all types of backlog items, including those related to DevOps, Trello, GitHub, or any other platform.

    How to create meaningful, yet efficient titles?

    Without a meaningful title, you need to drill down into the details. If your backlog is substantial, it quickly becomes time-consuming and tedious to drill into each and every item to see what it's about. Even worse... next time you visit the backlog, chances are you won't remember the details and will have to re-read every PBI again!

    Fix menu bug

    Figure: Bad example – What bug? How important is this?

    🔥 🐛 BUG | Menu disappears on mobile devices

    Figure: Good example - "Fire" emoji to bring attention to the PBI's importance, "Bug" emoji to indicate the PBI type, and a clear description of the issue

    Don't

    ❌ Be generic (e.g. "Fix bug in site")
    ❌ Write a novel in the title
    ❌ Ignore the importance of urgent PBIs

    Do

    ✅ Be specific (e.g. "{{Area}} | {{behaviour}}"). See our rule to order of instructions
    ✅ Prefix the area/form
    ✅ Identify its urgency (e.g. 🔥)
    ✅ Identify the bugs (e.g. "Bug" and/or 🐛). Bugs are special case - they should have greater visibiliy
    ✅ Use emojis. See our rule on emojis in Scrum

    Good PBI titles examples

    Using this structure: {{ EMOJI FOR PBI TYPE }} {{ BUSINESS AREA TOUCHED }} | {{ SHORT DESCRIPTION }}

    Bugs:

    🐛 Newsletter form | returns HTTP 500

    Features:

    ✨ Newsletter form | Validate email address

    UI/Styling:

    💄 Header | Update site header with new logo

    DevOps/Infra:

    👷‍♂️ DevOps | Add ephemeral deployment slots for PRs

    Urgent tasks:

    🔥🐛👷‍♂️ SysAdmin | Northwind app inaccessible through company VPN


    Other examples:

    🐛 Invoices | Invoice totals are rounded incorrectly

    ⚒️ Infrastructure | Implement staging deployment pipeline

    ✨ Clients page | Add create/edit client fields 

    Great titles are also important on Pull Requests, and email subjects.

    Emojis

    Love them or hate them, emojis have become a staple in the development world. As the old saying goes... "a picture is worth a thousand words". You can use emojis (responsibly!) to categorize PBIs/Issues/PRs/Emails, as well as bring attention to important items in a way that is easily interpreted by other people.

    Regardless of whether or not you choose to adopt the emoji language, you should always be mindful of the title's text.

    Always ask yourself: "Can a developer (or Product Owner) interpret the task and its importance without needing to dive into the details?"

  10. Communication - Do you know the best chat tools for your employees?

    There are many tools used to communicate and collaborate online. The most efficient platforms for chats and calls are:

    We think Viva Engage could soon be decommissioned to reduce confusion.

    In China:

    use wechat for work
    Figure: Bad example - Jim uses WeChat for work and asks Luke to come to the Big Chat room

  11. Communication - Do you know the options for remote meetings?

    The de facto approach of communicating via group emails and sharing files via a patchwork of different services is difficult, with the potential for missed messages and files.

    Microsoft Teams is recommended for company meetings and for internal communication. It's designed to provide an easier way for small groups of people to communicate and collaborate.

    Microsoft Teams' winning feature is its tight integration with Office services and Groups, which allows users to seamlessly and securely switch between editing documents, shared dashboards and planners, and group chat, video and voice calls. The simplicity of just setting up a Team and having access to all these shared services — without the need to spend hours configuring them is part of what Microsoft sees as Teams' selling point. Teams integration with email also allows messages sent to a designated Team address to be copied to a conversation in Teams.

    What are the options?

    Zoom – is the leader in modern enterprise video communication, with an easy, reliable cloud platform for video and audio conferencing, chat, and webinars across mobile, desktop, and room systems. Zoom Rooms is the original software-based conference room solution used around the world in board, conference, huddle, and training rooms, as well as executive offices and classrooms.

    Microsoft Teams – Microsoft Teams came along and boasted some of the features that Skype for Business offered – predominantly persistent chat, instant messaging, individual and group voice/video calls, and scheduled meetings.

    Skype – an instant messaging app that provides online text messages and video chat services. Users may transmit both text and video messages and may exchange digital documents such as images, text, and video.

    Skype for Business – a solid communication product boasting multiple modalities and the ability to easily switch between them, as well as share a variety of content forms (e.g., desktop, application, whiteboard, poll). skype chat

    Figure: Bad example - Numerous group chats with no group name and therefore no way of tracking previous chats/files

    Teams chat

    Figure: Good example - Figure showing all of the team members. This group chat can be used over and over for project discussions with all data in one place and integrated with SharePoint.

  12. Do you know when to call first before emailing?

    To prevent downtime while waiting for a response from a client, or the topic in an email needs to be discussed immediately, you should always call first before emailing.

    Video: Resolving conflict - call before emailing

    Calling first can save valuable time versus waiting for someone to respond to your email, making you more productive. Calling first also saves time when discussing topics that are easier explained over the phone. (Do you seek clarification via the telephone first?)

    When you need to contact someone, the steps you should take are:

    1. If possible, ping them on IM asking "Can I talk to you"
    2. Call them
    3. If you do not get through, leave a voice message and send an email starting with “As per the voicemail I left for you…"
    4. After talking with the person, follow up with an email that begins with the words "As per our conversation"

    It is very unlikely a client will complain because you contact them too often, but it is likely they will if you only ever email, so do not be afraid of calling first before emailing.

  13. Do you know the importance of asking questions?

    A disproportionate amount of time is spent thinking about whether you got the right answers from the client (or in the software world "Did we get the right specs?"). However, asking the right questions is a very important part of this process.

    Topics:

    • The importance of questions
    • Curiosity based questions
    • Confirmation based questions
    • Asking questions is natural (by kids)
    • Tip #1: Choose the right time/avoid interrupting
    • Tip #2: Avoid waffling by asking v2 questions (avoid v1 questions + setup a backchannel)
    • Tip #3: Ask questions with added value
    • Tip #4: Ask open-ended questions (avoid yes/no questions)
    • Tip #5: Document the answers in the PBI/email as it can help others in the future
    • Upselling - the side value of good questions
    • The Retro

    Tip: This video has timestamps and won't show here. The timestamps are only visible if you play this on the YouTube App or YouTube website.

  14. Do you know you should write notes when an activity is going?

    During meetings, there is a lot of communication between you and the client. It is very hard to keep the entire conversation in your head; hence it is very important you take notes. Notes must be short but descriptive enough so that you can remember what the conversation was all about and what tasks were created during the meeting. It is also very important that you use appropriate tools e.g. Microsoft OneNote, Trello, Microsoft Word, Notepad++ and avoid tools like Notepad.

    The best tool for taking notes will depend on what sort of activity you are doing. If you are making a straightforward document, OneNote will suffice. However, if the activity involves creating a lot of new tasks, it might be worth using Trello to take your notes. Trello allows for the creation of multiple lists (such as "To do", "In progress", and "Done") and has an easy drop and drag interface to reorganise work items as required. It also allows for comments on any item created, and you can tag people so they are associated with items. That way each new task can be created, organised and assigned immediately. You can invite team members and clients to the board so everyone is on the same page with regard to progress and outcomes.

    write notes bad
    Figure: Bad example – Notepad is not a good tool as it cannot recover your content in case of disaster

    write notes good
    Figure: Good example – Notes from the meeting with a client were written in OneNote

    trello for notetaking
    Figure: Good example – Notes from a conversation organising presenters for upcoming user groups. The sessions are listed in month order and the speakers have been tagged in their respective events.

  15. Do you know how to loop someone in at the end of a meeting?

    As businesses become larger and more complex, it's harder for the decision makers to keep up to date with every product change or be in every meeting. Responsibilities for decision making cannot be delegated but gathering the information to make an informed decision can.

    One common tactic is to have a delegate attend the meeting on their behalf and then loop them in at the end, bringing them up to date with an executive summary.

    Here are some tips to doing this effectively:

    1. Ensure the meeting has an agenda

      • It should list the delegate (who is receiving the information)
      • The last 5 minutes of the meeting will be used to loop in someone else
    2. Take notes during the meeting
    3. Summarize the info/action items with the other people on the call
    4. Call up the person you want to loop in
    5. Loop them in (done by the delegate)

      • Lead with the main message and action items. For example, "We need to adjust X in product Y" or "We should look into using X on the next project"
      • Include a recommendation where possible
      • Group information around the most important themes
      • Consider it an executive summary - if you have to recite the meeting, then it isn't a summary. If everything is important, then nothing is important.
      • If the delegate says something incorrect the other attendees of the meeting have a chance to correct them

    With this strategy, the decision maker can get to the important points quickly. They can be told:

    • What's important
    • Why they should care
    • What action needs to be taken
    • What are the choices
    • What decisions have to be made and when
    • What is your position - don't leave out the recommendation

    Tip: If you can't add them to the summary, record a summary and send them a link to watch when they have time.

    They know that there is a lot more detail behind what appears to be a one-line summary. If they want more detail, they can drill down or ask for more information.

  16. Do you speak up about unfairness?

    Throughout your career, you might come across a scenario that feels unfair. In these situations, communication is vital for resolving conflict and making all parties feel content with the result. Let's take a look at some scenarios that may be perceived as unfair:

    • Someone might get a promotion when you felt you deserved it more
    • A group of employees might be left out of a public yearly bonus
    • A colleague might be put on a project that someone else is more suited to

    There are 3 perspectives to consider and each has different strategies for maintaining a good working environment.

    Manager

    Managers are human, and sometimes don't make the right decisions.

    • Avoid unfair situations - Steer clear of arbitrary decisions that could be perceived as unfair. For example, if you are going to choose who the best employee is, you better have numbers to back it up.
    • Communicate decisions - By communicating the reasons for every decision you set the right expectations for employees and prevent them from feeling frustrated.
    • Give a heads up - If you know someone might feel a situation is unfair, give them a heads up ahead of time.

    Receiver

    Getting an accolade or present is great but consider your colleagues.

    • Remain humble - You might feel proud of your new accomplishment and that's awesome. However, make sure you don't advertise or boast about it because that may cause resentment among your colleagues and foster a bad working environment.

    Neglected individual

    Missing out on an award can suck. What should you do?

    • Ask questions - Finding out the reasons for decisions will help you understand why it happened. That knowledge will be valuable to you in the future.
    • Speak up - If you feel things are unfair make it known tactfully. If it is bothering you, the longer you wait, the worse it becomes. Speaking up will give the person making the decision a chance to explain or rectify the issue.
    • Be reasonable - Everybody has their day of sunshine. Even if it doesn't totally make sense to you. It would be awesome if you can be genuine and privately send a congrats or even better do it publicly.

      "Always clap for your friends, even if their dreams come true before yours."

    Video: Two Monkeys Were Paid Unequally: Excerpt from Frans de Waal's TED Talk (2 min)

    Video: Speaking Up about Unfairness - with Adam Cogan and Jean Thirion (9 min)

  17. Do you find the positive in the decisions?

    Video: Fairness and Helping Each Other - 10 tips with Adam Cogan (8 min)

    Everyone wants a place where people help each other. Unfairness can really impact people in the workplace.

    It all starts with how you approach things, some people are better than others at dealing with unfair situations.

    Lets assume one of these common scenarios:

    • New great project – someone is assigned to it... someone is unhappy
    • New promotion – someone gets it, someone else is unhappy

    These might seem like unfair situations. People don’t want to be unfair... friends don't... bosses don't.

    Here are 10 tips for how you can manage unfairness.

    1. Gotta speak up - See Do you know to speak up?
    2. Happiness is relative - Unhappiness can come from comparisons with others. Instead compare yourself with your day yesterday.
    3. Get one thing in life, lose another - Can't have everything. When you are saying 'Yes' to one thing, you are saying 'No' to another.
    4. The 'Happiness Equation'
      Happiness = Expectations - Reality.
      If you want to be happier, then:

      • Reduce your expectations
      • Increase your reality
    5. Consider luck - Everyone wants to succeed in life. But what causes some of us to be more successful than others? Is it really down to skill and strategy - or something altogether more unpredictable? Sometimes peoples success is simply luck. Read the book "Fooled by Randomness"
    6. Compete with yourself by embracing Scrum – Competing with yourself is the best approach. The same with teams. In software, Scrum is the best way of working as you only compare yourself... or your team with what you did before. Using empirical data is the way to go.
    7. Understand intentions - Try to see yourself in others shoes.
      Understand that people don't want to be unfair. It is common to be assuming the wrong stuff.
    8. Be the 'squeaky wheel'

      "A squeaky wheel gets the most oil."

      Ask questions, and you will understand even better the logic your friend or boss is using. Bonus they now know this is a topic you have interest in... so they'll give you extra information.

    9. Have attainable ambition - You need expectations to be realistic enough to push you, not so much that it makes you unhappy.
      Overly ambitious people are often unhappy... they never get there! Sometimes people find they are never rich or successful enough...
    10. Celebrate other people's wins - Be at peace and in a place where you are pushing each other up, rather than climbing over each other. Everybody gets their days of sunshine. When others achieve a goal, be happy for them, send a nice message, 'like' their posts, etc.

      "Always clap for your friends, even if their dreams come true before yours."

    Do the above and you can have a culture of helping yourself and helping others.

  18. Do you know how to take effective notes?

    Taking effective notes is an important skill that can help you stay organized and remember important information. Whether you’re in a meeting with a client or jotting down tasks for your to-do list, it’s important to have a system in place for taking and organizing your notes.

    One key tip for taking effective notes is to avoid deleting old notes. It may be tempting to delete notes once they’re no longer relevant, but it’s often better to archive them or move them to a different location where they can still be accessed if needed. This way, you won’t regret deleting valuable information later on. However, moving it to a different place may make it hard to find.

    An even better way to take notes is to include metadata such as the date and time when the note was taken, as well as your name. This can help you keep track of when and by whom the note was taken, making it easier to find and reference specific notes later on.

    Here are a few examples of how this can be done:

    Example 1 - On an Invoice page with a notes field

    invoice notes
    Figure: Good Example - The invoice notes have date and name followed by details

    Example 2 - On your phone contacts

    contact notes
    Figure: Good Example - The phone contact notes have date and name followed by details

    By following these tips and developing a system that works for you, you can take more effective notes that will help you stay organized and remember important information.

  19. Do you escalate key updates and deliverables?

    Key updates on projects may include Done Videos, critical text additions, or specification documents. Typically, links to these deliverables would be added to the PBI that they relate to and the relevant people would be mentioned.

    critical update bad example
    Figure: Bad example - Automated notifications from project management tools can be easily missed or overlooked amidst other notifications

    critical update good example
    Figure: Good example - For visibility and to ensure all stakeholders are in the loop, you should also send an email to the relevant people

    Not every PBI will require an email, but if it is a key update or deliverable, it should be escalated. The developers would make this judgement call, although this could also be added upfront by the Product Owner in the Acceptance Criteria for the PBI. Here are the 3 scenarios:

    1. Standard PBI - needed but the outcome is not very interesting: Do the PBI, just following the DoD
    2. Interesting to someone - @ mention them
    3. Really important - Make sure it’s top of mind, email it

    For example, you can send an email similar to this to share a new Done Video to the relevant stakeholders. If you working on a big system or internal projects, include the feature area or project name in the subject for additional context.

    This email is especially important for stakeholders that don't use, want to use, or have access to the project management tools. If they do have access, remember to also @mention them in the PBI update.

    Sometimes the PBI work originated from an email, in which case you should reply to the email instead of starting a new email. This will allow stakeholders to have additional context.

    Notes:

    • Major bugs found on the product should also be communicated to the PO as soon as they are found, e.g. unable to create an invoice
    • You should be able to easily tell if a PBI was created from email. As per turn an email into a PBI before starting work
  20. Do you have corridor conversations?

    The hallway is your friend. It's a place where you can gather a lot of information informally.

    Formal meetings can have a "Us vs Them" feel - While the information collected and the conclusions of the Spec Review are presented formally at the end of the Review, it is important that the consultants convey key points to the client as they emerge through the course of the Review. The formal presentation is not the time to be presenting new information to the client.

    ProjectManagement Suprise
    Figure: Use corridor conversations to prevent nasty surprises

    Addressing key potential sticking points of budget and technology informally during the course of the Spec Review relieves the potential for unwelcome surprises during the Spec Review presentation. Canvassing the issues beforehand in casual 'corridor conversations' clears the decks for an agreement, rather than increasing the risk of heated discussions if you surprise a client at a formal meeting.

    Some other topics that should have corridor conversations are:

    • Estimated Cost and Time
    • Key Technologies
    • Key Infrastructure

    For example, ask the client "...building the cube will add around 2 months of development time, shall we leave this out of the current scope, or do you want it in?"

    Ensure that any discoveries or decisions are properly documented.

  21. Do you take ownership and follow up?

    When working on a task, you often need to wait for others to continue your work. In that situation, it's easy to fire and forget, meaning the task doesn't get done for a long time. No one cares about unblocking a task as much as the person doing it. That's why it's important for that person to follow the Take Ownership and Follow Up (TOFU) principle.

    That means taking ownership of the task and chasing the people you are waiting on until it gets done.

    What TOFU Involves

    There are 2 main aspects to TOFU:

    • Taking Ownership - Giving timely honest updates to stakeholders about progress
    • Following up - Proactively communicating with blockers (ideally chase them at least one a day)

    Why It's Important

    • Accountability: The TOFU principle fosters a culture of accountability, where individuals feel personally invested in the outcome of their work.
    • Clarity: Regular follow-ups provide clarity to all stakeholders, keeping everyone informed about progress, challenges, and changes.
    • Trust: Demonstrating reliability through consistent follow-up strengthens trust among team members and with clients or stakeholders.

    How to Do It Effectively

    1. Acknowledge and Accept: When a task is assigned to you, acknowledge it promptly and ensure you understand the requirements. If anything is unclear, seek clarification immediately.
    2. Communicate Proactively: Don't wait for someone to ask for an update. Regularly communicate your progress, especially if you encounter any roadblocks or delays.
    3. Set Clear Deadlines: Establish realistic deadlines for your tasks and communicate these with your team and stakeholders. If a deadline needs to be adjusted, communicate this change as early as possible.
    4. Use Tools to Your Advantage: Understand the best ways for following up effectively and leverage Scrum tools (e.g., Azure DevOps, GitHub, Trello) to track tasks, deadlines, and progress.
    5. Close the Loop: Once a task is completed, ensure all relevant parties are informed and that any necessary documentation is updated. Closing the loop is a critical part of the follow-up process, as it signifies that no further action is required. The way to do this for a task you received via email is to send a Done email. For tasks (e.g. a PBI) outside an email it is usually to add a comment.

    Common Pitfalls to Avoid

    • Overcommitting: Only take ownership of tasks you have the bandwidth to manage. Overcommitting can lead to missed deadlines and decreased quality of work.
    • Under-communicating: Assuming others are aware of your progress or challenges without regular updates can lead to misunderstandings and delays.
    • Neglecting the Big Picture: While focusing on your tasks, don't lose sight of how they fit into the larger goals and timelines.

    In Conclusion

    Embracing the TOFU principle is not just about completing tasks; it's about building a reliable, transparent, and efficient work environment. By consistently applying these principles, you contribute to the success of your projects, the growth of your team, and your personal development.

  22. Attention to Detail - Do you know how to make sure you've covered all your bases?

    Ensuring thoroughness and accuracy in your work is crucial, but it's easy to overlook important details when you're under pressure or rushing to meet deadlines. Attention to detail can make or break a project. Consider the classic mistake of sending an important email without the attachment mentioned in the text. Such oversights, while seemingly minor, can undermine your professionalism and the effectiveness of your communication.

    The ultimate way to ensure your bases are covered is to get someone else to check the work as per the "checked by xxx" rule.

    However, before you get the work checked, you should cover as many details as possible by yourself.

    What to do before a "Checked by"

    Preparing for a "Checked by" is essential because it ensures you have your ducks in a row and keeps the "Checked by" call as short as possible.

    That makes it a smooth experience for the person you are calling and ensures they will have a good impression of your work.

    Here are some things you should do to prepare:

    1. Double check your work

    Before sending out an email or finishing a task, do a once over of the final end product to ensure you are happy with the output.

    2. Use ChatGPT and spelling/grammar checkers

    ChatGPT is great at serving as a second set of eyes. Pass in the email or information you want to convey and ask it if you missed anything. Even better, use Reflexion to critique your work. The results will give you confidence that your response is correct and adequate.

    Spell checkers like Grammarly are also great tools. They check your work on the fly and flag any issues immediately.

    3. Take your time

    It's easy to feel rushed when you are under the pump, but even in such situations it's important to take the time to do a task properly.

    As you do the task, meticulously check each step, and check and re-check your work as you go. Better to deliver the task a little bit late than to deliver it with a lot of mistakes.

    4. Use a checklist

    If you're doing a task that involves a long set of steps, turn it into a checklist. Copy the tasks into notepad and strike them out as you go, that way you know they are done.

    5. Break tasks into smaller parts

    Tackle large projects by breaking them down into more manageable parts. This can help you focus on the details of each segment without feeling overwhelmed.

    6. Don't switch focus

    Try to focus on a single task until it is completed. If you juggle multiple tasks you are likely to forget things in both tasks and end up with a worse result.

    7. Rest and take breaks

    Ensure you're well-rested and take regular breaks. Fatigue can significantly impair your ability to pay attention to details.

    Conclusion

    By implementing these strategies, you can significantly enhance your attention to detail, leading to higher quality work and fewer mistakes. Remember, being detailed-oriented doesn't mean being perfect but rather being diligent and conscientious in your efforts to minimize errors and oversights.

We open source. Powered by GitHub