How to make small, valuable async standups

How to share the current status of the development especially working remotely? How to make the message more understandable, valuable and short at the same time? There are some basic requirements for standups we defined from our experience.

Why standups are so important #

Here are the main reasons why standup is helpful and should be well worked out:

• It helps to notice other participants what issues you are working on, your progress, blockers or help wanted. Especially it is valuable for teams with more than 2 people working remotely and/or asynchronously.
• It helps to build trust with the Product Owners (or their representatives). It is a way to involve the clients in the development process, keep them informed about the difficulties or successes.
• It could give an ability to react in advance to issues and not waste the resources in places that are not critical and find the workaround acceptable for both client and developer.
• It helps to track the developer’s time spending, build the correct expectations, and be on the same wavelength with the developer.

A well-organized standup can save time, resources and money > if it is informative and eye-catching.

The common mistakes when writing standups #

The poorly written standup will not be read. In this case, its entire value is reduced to zero. The main reasons people stop paying attention to standup are:

• Too often or rare posting, no stable frequency.
• Too long, too much information, lack of clear identical structure.
• Does not give an idea of ​​the process, too superficial.

The frequency of the standup #

The frequency of the standup depends on its type:

• Daily standup. Should be posted when the developer starts working once a day. The main goal is to inform about the work done on the previous working day, which will be done during the current working day, and which problems were met.
• Status update. Should be posted every 2-3 hours. This type is very helpful when there is no absolute trust from the client or team (for example at the beginning of the collaboration). This is the way to show which steps were done to achieve the success, why they were done, what conclusions were done.

Required structure #

In order to be helpful, standup should contain the links to the tasks that were in progress (to find the description quickly). It should be clear how many tasks were completed / in progress, and which locks were met that prevented the tasks from completing. The preferable format consists of the items:

• Yesterday (required) It informs about the work that was done and displays the progress in the tasks.
• Today (required) Should contain the next steps that are going to be done, the plan for the current day.
• Problems/Blockers (optional) Displays the problems that prevent you from moving on, the next steps for their solving, indicates the person whose help is needed.

The main recommendations #

• Always keep in mind that your message should be understandable for non-technical readers, try to use specific terms as little as possible.
• The message should be clear, show what benefits you brought to the project by the work you have done, and what benefits the customer will receive.
• If you worked on some research, the message should contain the results, what succeeded/failed, and for what reason, what conclusions were made.
• Start the message with a description of the problem. And then describe what was done to fix it or if it is a simple problem then just say ‘fixed’.

Here are some common cases:

1. If you enter sentences like fixed search then that makes the client wonder what was fixed in search. That is why it is important to describe in a bit detail what task was done. Think about it.
2. Do not make an entry like Fixed the link for Listing Inactive in Admin panel. This entry does not tell the client what work was done. Yes, the link got fixed but the client still has no idea what was the problem with the link to begin with. A better message would be Clicking on the inactive link in the Admin panel was not doing anything. Fixed the link so that now when the inactive link has clicked a list of batches in inactive status are displayed.
3. Do not use in the standup/sentence the word combinations like worked on listing form tests. In this case the message should mention what functionality was tested. The better way to say such as Added following test cases: 1) user clicks on Listings. 2) user clicks on active 3) user clicks on delete link on the first record.

As a summary #

After reading the standup, there should not be any questions about how the day was spent, what tasks were solved, what difficulties arose, what next issues will be solved. That will help to make the collaboration more transparent and comfortable without stress and unexpected bad news.