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 two weeks 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:

  1. What did you do yesterday?
  2. What will you do today?
  3. 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 Platform board.

However, any unplanned breaking/critical issues that need to be addressed immediately (e.g. production environment brakes) need to be added to the Launchpad kanban board.

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
  • Process
    • 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
  • Process
    • 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
  • Process
    • 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
  • Process
    • 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
    • Task is moved to “Testing” status
    • Unit tests passed
    • Code/PR reviewed
    • API documentation is ready
    • Testing scenarios prepared
  • Process
    • QA team writes and executes API/Integration tests based on the plan
    • If any issues are discovered, the task/user story is pushed back again to “In progress”. Developer needs to fix the issues depending on the feedback.
  • Exit criteria
    • All API tests pass
    • User story/Task is moved to “Done” status

6. Design & prototyping

The product specifications and low fidelity mocks are transformed into high fidelity mocks and prototypes.

  • Entry criteria
    • Specs and mocks are prepared and approved
  • Process
    • Designer creates mocks and prototypes
    • All assets are shared with the Product team
  • Exit criteria
    • Figma mocks are prepared aligned with these requirements
      • A link to a prototype is shared
      • Links to different screens is shared
      • New components created and added to the Design system (if needed)
    • Product manager reviews and approves the mocks

7. Frontend software development stage

Frontend teams builds UI for the functionality  implemented by the backend team.

  • Entry criteria
    • The associated backend task is moved to “Done” status
    • A task for frontend is created by Product Owner with the linked specifications, product mocks
    • High fidelity mocks/prototypes are ready
    • API documentation is ready
  • Process
    • Frontend team ananalyzes the specifications, product mocks, APIs and breakes down the task in to multiple subtasks during the sprint planning session.
  • Exit criteria
    • Unit tests passed
    • Code/PR reviewed
    • Deployed to the test environment
    • Task is moved to “Testing” status

8. Functional testing stage

Product owner manually test the functionality implemented by the Frontend team.

  • Entry criteria
    • The associated task is moved to “Testing” status
    • Unit tests passed
    • Code/PR reviewed
  • Process
    • Product owner prepares and executes functional testing scenarios based on the product specifications
    • If any issues are discovered, the task/user story is pushed back again to “Needs fixes”. Developer needs to fix the issues depending on the feedback.
  • Exit criteria
    • All tests pass
    • Task is moved to “Done” status b the product owner

9. Deployment stage

Initiates the deployment to production environment of the functionality that was tested and approved in the test environment.

  • Entry criteria
    • End to end integration testing is done
    • Regression testing is done
    • Product documentation (help.intempt.com) is created
    • Approved by Product owner
  • Process
    • Before the end of the sprint (Friday) engineers that have developed a feature pushes their PR(s) to the master branch
    • Engineers update the PR list to add the repos that have active PRs
    • On Monday, Product owner deploys to all PRs on the master branch to the Production environment
  • Exit criteria
    • Regression tests on production environment passes without errors

Work at Intempt

If you want to work at Intempt you can check our job ads here