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.

Sprints

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

Cadence

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:

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 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