Skip to content
Intempt's Employee Handbook

icon picker
How we work

Intempt is structured for speed, autonomy and innovation.
Many traditional organizations have big, separate functions. You have a product team, an engineering team, customer support, and so on. This slows things down when you scale because there are more layers of communication and complex approval chains. This stifles innovation - you have to get your boss to talk to someone else's boss to get work done. It also means that people can't really see the impact of their work.


At Intempt, we work in short development iterations we call sprints.


Each Sprint is one week long. A new Sprint starts immediately after the conclusion of the previous Sprint.

Sprint Planning

Each sprint begins with sprint planning, where the Scrum Team gets together with the Product Owner to decide which cards will be pulled from our main Product Backlog into the Sprint Backlog.
Each Sprint is organized as a separate Scrum Board. This makes it really easy for us to concentrate upon needs to get delivered in that particular Sprint without getting distracted by what was done in the past or what remains to be done.

Sprint goals

Before starting the sprint, each team member commits to their goals for the sprints, and we publish them on our Goals page.

Daily standups & check-ins

Every day, we have daily standups and evening check-ins to ensure that everyone is aligned with the plans - no one is blocked.
The purpose of these meetings is to inspect progress toward the sprint goals and adapt the backlog as necessary, adjusting the upcoming planned work.
Before each meeting, each pod member needs to answer these three questions:
What did you do yesterday?
What will you do today?
What blockers stand in your way?

Backlog grooming

Product backlog grooming is held to ensure the backlog is ready for the next sprint.
During a product backlog refinement meeting, the team and product owner discuss the top items on the product backlog.
Jobs to be done during the meeting:
Identifying and removing items that sounded good but are no longer relevant.
Improving clarity and preventing misunderstanding by adding details in preparation of implementation. For example adding examples, constraints, edge cases, and acceptance criteria.
Splitting large items into smaller ones. Smaller items are more focused and manageable and are easier to size.
Sizing items, including re-sizing them
when they’ve sat in the Product Backlog longer than intended.
as a sanity check when they’re up for implementation.
Prioritizing items, and re-prioritizing them when you add more details or gain new insights.
Identifying risks and obstacles for items close to implementation.

Show & Tell

At the end of each week, we perform a demo/Show & Tell meeting.
This meeting allows us to celebrate the sprint’s work and talk about what we learned. It’s also a chance to bring the team together, let the team you’re working with know what you’re up to, highlight progress where dependencies exist, and keep everyone connected.

We write issues, not user stories

The only requirement when creating issues is to add a title, team, and status like backlog or todo. This lets us to create issues fast without it taking away from your core work. We don't think creating issues should be a chore and we don't write user stories.
When writing issues we break them down as small as possible and assign them to a single owner. We think that's really important. If multiple people are involved, we'll break down the issues into sub-issues and then assign those. For the most part, everyone on the team writes their own issues or if they're assigned an issue, gets to decide how to execute it.

Why we don’t write user stories

User stories have become a useless ritual that feels good but wastes a lot of resources and time.
THey are a roundabout way to describe tasks, obscuring the work to be done.
Are time-consuming to write and read and can silo engineers into a mechanical role where they code to the issue requirements instead of thinking about the user experience holistically at the product level.
Are complicated and difficult to scope - they bring what should be product-level details into the task level.
They don’t match how we communicate about software in real conversations.

Ditching user stories doesn’t mean you should forget about the user. You can collect feedback on features. Write product and project briefs. Describe user needs and value there.
We just forget the user story encoding and write what needs to get done.

Sprints vs. Launchpads

The standard work process is to follow a 2-week sprint cadence. That means focusing on work that is planned during the sprint.
All status updates during the SCRUM sprint should be performed in the .
However, any unplanned breaking/critical issues that need to be addressed immediately (e.g. production environment brakes) need to be added to the .
Fixing these issues will not follow the usual sprint process that involves estimates, user stories, etc.
Engineers that are assigned issues in the Launchpad board would need to stop their on-going sprint tasks and transition to solving the issues.

Development flow

1. Planning stage

Clearly define the scope and purpose of the application.
Entry criteria
A new feature/functionality is proposed by Product team/customers/eng team members
Feature is analyzed against the current platform functionality, market demand, and effort to implement
Report is prepared if the feature is worth developing
Exit criteria
Product pod members jointly agree on the to-be implemented feature and assign priority to it (high/medium/low)

2. Product documentation stage

Determine what the feature is supposed to do and its requirements.
Entry criteria
Feature is approved by the Product team members
Product owner creates feature specifications and mocks
Prepared specifications are presented for approval to the Head of Product and Platform Architect.
Exit criteria
Head of Product and Platform Architect reviewed and approved documentation
Feature is prioritized and added to the GANTT roadmap

3. Backlog grooming

Developers scope and estimates the tasks that are planned in the roadmap.
Entry criteria
Specs and mocks are prepared and approved
Specs & mocks are analyzed the the assigned engineer and broken down in technical tasks. Each technical task needs to have an estimate (in hours) assigned.
Exit criteria
Functionality is broken down into technical tasks
No tasks should take more than 2 days to complete
All tasks for a single feature needs to be grouped in a single epic

4. Backend software development stage

Engineers start to work on the product implementation.
Entry criteria
Specs and mocks are available.
Architecture is proven and signed off by the stakeholders.
Technical tasks are created and estimated
Developer works on the tasks during the sprint
After finishing the development, developer prepares the API testing collections
Exit criteria
Unit tests passed
Code/PR reviewed
API documentation prepared
Acceptance criteria prepared for the QA to test
Deployed to the test environment
Non-functional tests passes (required only for large features)

5. API testing stage

QA engineers automate the APIs addressing the specific changes introduced by Backend team. Discovered bugs are assigned to the task owner.
Entry criteria
Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
) instead.