Template for standup meetings

[robby1066]

TL;DR: This feature would add the ability for people to use Keep Posted to organize an asynchronous alternative to a daily standup meeting by having team members record their updates via their webcam. Updates would then be compiled into a single message and distributed to everyone on the team.

What's the problem you're hoping this new feature will solve?

Team members may use a 'standup' format to communicate their status and any issues that are blocking them from accomplishing tasks that they're focused on. These meetings are recurring, and may take place daily, weekly, or on another interval.

There are many reasons it may be challenging for a distributed team to gather at the same time. Being able to check in asynchronously may be a useful alternative and has been asked for by several people interested in trying Keep Posted.

What could be good about asynchronous standup meetings?

• Team members in very different time zones can more easily participate
• More flexibility on when a person wants to engage with the message—it doesn’t have to interrupt a flow state they may be in
• Options for playback at high speed or navigating through updates non-linearly
• People who are not able to make a scheduled meeting for any reason are able to participate
• One less meeting on the calendar—when one less meeting is desirable*

What could be bad about asynchronous standup meetings?

• Unclear how feedback will be given—If someone says they are blocked, how can someone respond to that with support?
• One less meeting on the calendar—when real-time human contact is desirable*

What needs to be explored?

• How structured do standup meetings tend to be?
• How many people are involved in standup meetings?
• What actual needs do they fulfill?
• What are the actual frustrations other people experience from them?
• How do managers experience them vs. individual contributors?
• Are standup meetings a chore, rejuvenating, or a bit of both for a team?
• How do experiences of standup meetings differ from team to team?
• What beneficial feedback generally gets given in standup meetings?

Description of feature

Initial idea - Subject to change

A 'Standup' message template in Keep Posted would allow multiple people on the same team to answer a structured question (or set of questions) that would then be compiled into a complete message for sharing among the team at a predictable time.

There should be creator-level control over the questions answered by team members. These questions are likely to be structured and the same questions will be asked to everyone participating. It’s also likely—but not guaranteed—that the same questions will be asked at every standup instance for a team. There may be exceptions to this where a specific question needs to be asked, or the stock questions may be changed now and then.

Example standup meeting questions:

1. What did you do yesterday?
2. What will you do today?
3. Anything blocking your progress?

The person organizing the standup message (the message creator) should be able to easily kick off the process of collecting input from the team. Ideally, message creation and prompting team members for responses can be condensed to a single-action green path (one-click kickoff), with options for making adjustments if needed.

When team input is collected, the organizer should be notified so they can build and distribute the message. Alternatively, there could be an automated cutoff time (‘record your standup update before noon’) after which the message is automatically built and distributed.

Alternatives and workarounds

Currently, a collaborative message could be created asking the same questions to each person. It would be tedious to create if the team was more than a few people, especially if these were a recurring activity.

Additional context

https://geekbot.com/blog/daily-standup-meeting/
https://www.atlassian.com/team-playbook/plays/standups

[robby1066]

Some thoughts on the interaction model that would fit here.

What roles are involved here?

• Message organizer: this is the person who initiates the message and causes the relevant people to be notified about recording a clip
  • This maps to the "message creator" role in other Keep Posted messages. This is the person who the message is ultimately tied to.
  • It's not guaranteed or necessary that the organizer actually records anything for this message. They may just be facilitating and curating
• Message Participant: this is one of potentially many people who will record a clip for the message
  • In the context of a standup message, this would include all the people on the team who were giving an update
• Message Viewer: this is any of the people who will be viewing—and potentially responding to—the message once it is compiled and distributed
  • This likely includes the Message Organizer and the Message Participants
  • It may also include other people, such as team members who couldn't participate for whatever reason, department heads, or execs, depending on the reporting processes in the organization

What high level interaction flows make sense?

Create & Distribute - Version One: open invite

1. Organizer creates the message in Keep Posted
   • Specifies questions to answer—which will be saved as defaults for future messages
2. Organizer distributes link in Slack
3. Participant follows the link
   • they log in or create an account if they don't yet have one
   • they end up on the page prompting them to record their status update
4. Participant records their status update
5. Organizer is notified when all clips are complete
6. Organizer builds the message
7. Organizer distributes link to the new message
   • Share the link in Slack
   • Share the link in Email

Question: How does the system know who is expected to record an update?
Question: Is there ever a danger of an unauthorized person recording a clip?

Create & Distribute - Version Two: specify participants

1. Organizer creates the message in Keep Posted
   • Specifies questions to answer—which will be saved as defaults for future messages
   • Selects people to invite to participate—an account will be created for invitees who do not already have accounts
2. Keep Posted lets participants know that there is a message to contribute to
   • If Slack info available, it's possible to do this by a DM
   • Email is the fallback notification mechanism
3. Participant follows the link and logs in if they are not logged in already
4. Participant records their status update
5. Organizer is notified when all clips are complete
6. Organizer builds the message
7. Organizer distributes link to the new message
   • Share the link in Slack
   • Share the link in Email

Question: Should Keep Posted automatically build and share the message when all clips are recorded? What is the value of the organizer taking a final pass over everything before building?

Create & Distribute - Version Three: automate everything

1. Keep Posted is aware of the title of the daily standup event on the team calendar, and detects that the virtual event is scheduled to start
2. A message is automatically created (still owned by the Message Organizer)—the predefined standup questions are attached to the instructions for Participants
3. Keep Posted uses the people attached to the calendar event to assign participants and sent invitations when necessary
4. Participant receives an invitation
5. Participant records their status update
6. When all clips are complete, Keep Posted automatically builds the message
7. Keep Posted distributes link to the new message in pre-defined channels
   • Share the link in Slack
   • Share the link in Email

[robby1066]

Design Doc: Interaction Flows

Design Doc: Wireframes

[robby1066]

Thinking through this template, it's becoming apparent that this could be abstracted into a more general use-case. It's really useful for any situation where you want to hear a response to a specific question from a group of people.

The "standup" meeting is just one of those. Others include:

• Recurring status meetings that don't fit the standup model (the name may be alienating to people unfamiliar with scrum?)
• Icebreaker check-ins to help a remote team get to know each other better
• Project postmortems. (what's something you learned from ______?)
• Less frequent general status updates (Describe your OKRs for next quarter)
• Structured feedback or input from customers or clients (In less than a minute, describe whats most valuable thing about our product for you)

There are many others.

How should that be modeled? It's probably not ideal to have the UI say "want to do a standup message? Easy! Just go to the Team check-in, icebreaker, customer research, etc... section."

One option would be to have a generic format that can be presented in multiple contexts on the front end, to shield the users from the complexity and think about their specific task rather than wading through too many use cases.

[robby1066]

Example of the template UI (in progress, still needs some cleaning up)

[robby1066]

Launched on Feb 26. Still need to update the documentation. I'll close this as soon as that's done.

[robby1066]

Added documentation to the create messages page in the wiki.

Closing this issue.