What sprints and retros are
Many development teams work in sprints. A sprint is a period of one or two weeks in which the team works on a set of tasks chosen in advance. When one sprint ends, the next one starts right away. This way of working comes from Scrum, a framework used by many IT teams.
In each sprint the team holds several meetings. At the start there's planning, where the team decides what to do in the sprint. Every morning there's the daily, a short call about who's working on what. At the end there's the demo, where the team shows what it built, and the retrospective, or retro. The retro isn't about tasks but about the work itself: what helped, what got in the way and what to change next sprint.
How sprint planning works
Planning happens on the first day of the sprint. For a two-week sprint, one or two hours is usually enough. The product owner brings the backlog sorted by priority and explains why the top items matter. The team states the sprint goal in one sentence, for example "Users can pay for an order by card in the app". Then it takes on tasks for that goal based on how much it got done in past sprints. Large tasks are split into pieces that can be finished in a few days, and each one gets an assignee. After the meeting, the team has a goal and a task list for the sprint.
How demos and retros work
On the last day of the sprint, the team shows what it built at the demo. The product owner and stakeholders watch, and their feedback goes into the backlog for the next sprint.
The retro comes after the demo and usually takes an hour. Everyone answers three questions: what helped, what got in the way, and what to try next sprint. The team votes on the points most worth discussing and makes decisions on two or three of them. Each decision needs an owner and a due date, otherwise the same problem is back a sprint later. The next retro starts by checking the previous agreements.
Besides "helped, got in the way, try next", teams use other formats: Start, Stop, Continue, or Sailboat, where the wind is what helps, the anchor is what slows the team down, and the rocks are risks. Teams switch formats when the answers start repeating.
Example: a mobile app team's sprint
A team of five builds the mobile app for an online store, and a sprint lasts two weeks. At planning, the team sets the goal "Users can pay for an order by card in the app". Out of 11 tasks in the backlog it takes on 8, because it closed 7 or 8 in each of the last two sprints. At the retro, the point with the most votes is "PRs wait three days for review". The team decides to name a review on-call person for each sprint and to review PRs within a day. Dima is on call first, and at the next retro the team will check whether it helped.
What goes wrong when everything stays in the call
Nobody writes the outcomes down. The team spends an hour on what goes into the sprint, and the goal and agreements stay in the call. A week later the developer and the designer remember the sprint scope differently, and the retro decision has no owner and no due date.
The same people do the talking at retros. On an hour-long call, three or four people speak up. The rest agree with them or think of their point after the call is over.
What Pachca has for sprints
Pachca's own features are enough for planning and retros.
- Threads. A thread is a discussion branch under a specific message. The sprint retro runs in one thread, and the chat shows it as a single message with a comment count.
- Reactions. People vote for retro points with a reaction, and the vote count shows under each point. Search by emoji finds messages with a given reaction.
- Calls with an AI summary. In chats, transcription turns on by itself when a call starts. After the call, the AI summary and the full transcript land in the thread under the call message, along with the recording if it was on.
- Pinned messages. The sprint goal and the retro outcomes get pinned in the team chat. For the rest of the sprint, you find them with the pinned messages filter in the chat search.
- Reminders. A reminder is attached to a chat and gets an assignee and a due date. When it's due, the assignee gets a notification.
- Scheduled messages. The retro questions are written in advance, and the message goes out to the chat on the day and at the time you picked.
How to set up Pachca
A team chat. Run planning, demos and retros in the team chat, for example "[Team] Mobile app". Six months later, the team lead can search for what was agreed in any sprint. How to name chats is covered in the article "How to organize communication in your team chat app".
A summary prompt. Open the arrow next to the video call button in the chat header and choose "Configure AI summary". In the "Summary prompt" field, write what the outcomes should include, for example: "The sprint goal in one sentence, then tasks with assignees and risks". The prompt applies to every call in the chat, so write it so that it works for demos too.
Retro questions on a schedule. Write a message with the retro questions, choose "Schedule message" in the send options and pick the last day of the sprint. If your sprint lasts a week, turn on a weekly repeat. If it lasts two weeks, schedule messages for the next few sprints at once.
Notifications from your tracker. If the team tracks sprint tasks in GitLab or Jira, a bot can post notifications about them to Pachca. GitLab has a ready-made integration, and Jira connects through a webhook, following this guide. Send the notifications to a separate chat, for example "[Releases] Mobile app", so they don't get mixed in with the discussion.
Sprint planning
To keep planning outcomes from staying in the call, the sprint goal and agreements get written down where the team will find them a week later. In Pachca, the team lead starts planning with a call from the team chat, using the video camera icon in the chat header. When the call ends, a message about it appears in the chat, and the AI summary and the transcript land in its thread. Whoever couldn't join reads the summary and asks questions in the same thread. AI sometimes gets names and numbers wrong, so check them against the transcript. Post the sprint goal as a separate message and pin it in the chat.
Thread
[Team] Mobile app
I'll send the copy by Wednesday
Daily updates
A daily standup is a short morning meeting where everyone says what they did yesterday, what they're doing today and what's blocking them. When a team works across time zones, the daily often happens in writing. In Pachca, the team lead sets up a repeating scheduled message "Today's updates" for 10:00 on weekdays. Everyone answers the same three questions in the thread under it. Calls happen only for blockers. How to collect updates with a bot form and get a digest is covered in the use case "How do you run a daily standup in 15 minutes?".
Sprint demo
Stakeholders and neighboring teams often miss the demo, so it gets recorded and questions are collected in one place. In Pachca, if you turn on call recording for the demo, the recording lands in the thread under the call message together with the summary. Whoever missed the demo watches the recording and asks questions in the thread. If the demo happens without a call, the presenter posts the video and the slides to the chat in one message, and questions go in the thread under it.
[Team] Mobile app
9 members
Sprint 14 demo: the new onboarding. Here's the walkthrough recording and the slides with metrics, questions go in the thread
Async retro in a thread
A retro doesn't have to happen on a call. The team can collect answers in writing over a day or two and use a call only for the main points. In Pachca, this kind of retro runs in a thread. A developer who stays quiet on calls has time to put their point into words and post it in the evening, and a designer eight hours ahead replies during their own working day.
Ask the questions. On the last day of the sprint, a message arrives in the chat: "Sprint 14 retro. By Friday 16:00, post in the thread what went well, what didn't and what we'll try next sprint". Attach the burndown chart or a report from your tracker so the conversation is about facts.
Collect the answers. Ask people to post each point as a separate message, so each one gets voted on separately.
Vote with reactions. Agree that 👍 means "worth discussing". A day later the facilitator sees which points got the most votes.
Discuss what matters most. Take the two or three points with the most votes and discuss them in the thread or on a short call. If opinions split on the call, create a poll right in the call.
Write down the agreements. The retro facilitator posts the outcomes to the chat in one message, names an owner for each point and pins the message.
Thread
[Team] Mobile app
Sprint 14 retro By Friday 16:00, post in the thread what went well, what didn't and what we'll try. Give a 👍 to the points worth discussing
Didn't go well: flaky tests in CI, we reran the pipeline three or four times
Went well: the onboarding designs were ready before the sprint
Let's try: record the demo in advance so it doesn't depend on the staging server
If the team wants answers to be anonymous, they're collected with a bot form, and the bot posts them to the thread without names. You can build a bot like that in n8n without code, as described in the use case "How do you automate routine work with n8n and AI agents?".
How to follow through on retro agreements
A retro agreement gets done when it has an owner and a due date, someone reminds people about it, and the next retro starts by checking it. In Pachca, create a reminder for each agreement: in the team chat, click the purple checkbox icon in the top right corner and choose "New reminder". Set an assignee and a due date, for example the last day of the next sprint. The reminder is attached to the chat, all its members see it, and the assignee gets a notification when it's due.
Start the next retro with the chat's list of reminders. It opens with the same checkbox icon and shows which agreements were done.
Retro after an incident
After a production incident, the team also gets together for a retro and works out what happened, why, and what to change. How to run that kind of review in Pachca is covered in the use case "How do you run incident reviews and write postmortems?".
Where to start
Start with your next retro. Schedule a message with three questions for the last day of the sprint and agree to vote with 👍. After the retro, pin the outcomes and create reminders with assignees. At the next retro, check the list of reminders to see which agreements were done.
Frequently asked questions
For a retro built on three questions, a thread and reactions are enough. A whiteboard helps if the team sorts cards into themes on a call. Post the whiteboard link in the retro thread, and write the outcomes in the chat so they can be found by search.
Usually the Scrum Master or the team lead. You can rotate the facilitator every sprint, and everyone will take turns writing the outcomes.