Explore

Evolve Plan

Basis Labs

Purpose

Fast, high quality development for clients who want to ship quickly, learn fast and deliver products that make a mark in their industry.

Helpful terminology

Before we embark on this crazy journey we call “App Development”, it would be helpful to establish a shared dictionary of somewhat jargony yet useful words:

Sprint: A time-blocked period of work in which we tackle as many of our planned features as possible. We work with you to prioritise and scope the features before each sprint.

Scope: Encapsulates the sometimes unpredicatable and creative process of accessing a new feature request before outlining its requirements and giving a rough estimate for how long it will take to complete.

Backlog: Where all tasks live before they are assigned to a sprint. If a sprint is a nightclub, then the backlog is the line of people shivering in the cold (but super eager to come in and dance!)

Feature: This could represent some new functionality or improvement to the app, or more of a behind-the-scenes update to improve performance, security, or reliability moving forward. At its core, this is simply some change that’s going to happen to the application.

Process

Picking a plan

Everything we do happens in a sprint, and a sprint is always three weeks long with one week reserved at the end for light feedback and planning of the next sprint.

Before we start work you’ll decide how much developer capacity you want to reserve within the next sprint. This works just like your mobile data plan: you get a certain amount of capacity to use on whatever you want. Of course, some things use up more capacity and some less. How much capacity is appropriate is something we can help you with but ultimately it boils down to how many features you want to prioritise getting done in the next three weeks. Below you can see an outline of your capacity options.

Plan options

Plan options

Not synced yet

Row

Level

Description

Credits

Amount

Availability

Two days

Good for occasional small tweaks, fixes, and small feature additions.

$2,160.00

Available

Four days

One or two solid new features.

$4,320.00

Available

Eight days

A big, complex new feature, or several medium ones.

$8,640.00

Available

Sixteen days

Close to a full time effort.

192

$17,280.00

Not currently available

There are no rows in this table

⁠

We use credits to track the amount of work each feature takes; this is the equivalent of a megabyte in your mobile data plan. You can get a feel for how credits map to work below:

Estimate levels

Estimate levels

Size

Credits

Rough time reference

Tasks Example

XS

0 - 1 credits

30min or less

Add a new category filter to a list of properties

S

1 - 3 credits

30min - 1.5 hours

Create a new table view for a list of transactions using pre-existing UI

M

3 - 6 credits

1.5 - Half a day

Create a sign up/login page using pre-existing UI

L

6 - 12 credits

Half - Full day

Setup credit card payments with the Stripe API

XL

12 - 24 credits

1-2 days

Implement a reviews system, with email reminders and the ability to add and view reviews for booked properties

XXL

24 - 48 credits

2-4 days

Add bookable 'Experiences' feature, with support for creating experiences, searching for experiences and booking experiences

There are no rows in this table

⁠

Planning a sprint

Planning each sprint happens in three distinct steps:

You’ll add all the features and updates you want done to the Backlog

We’ll then give an estimate for how many credits we think each one will take. We might ask some clarifying questions. We’ll include the uncertainty and risk in our estimate.

Finally, we’ll have a conversation with you about what takes priority. This is just a triaging of the tasks where we decide that adding in that new commenting feature and connecting with your CRM are must haves for this sprint, while adding in that new admin view can wait till the next sprint.

We’ll give estimates using T-Shirt sizing (see above). The idea of this is to develop a shorthand way of talking about task complexity. Over time it will become more intuitive, but we’ve given a rough time estimate and example of a feature in the table as well to help initially.

Please note that while we’ll always endeavour to make our estimates as accurate as we can, there is often unforeseen complexity and unknowns that make truly spot-on estimates nigh on impossible (if that wasn’t the case, a robot could do our job. Maybe one day....).

All that is to say, we may occasionally get features which take less or longer than our estimate, but as mentioned

below⁠

, we’ll do our best to communicate this timely and adjust our planning accordingly.

Running a sprint

Once the sprint starts we’ll tackle each feature, working our way through the queue and tracking the credits used so you can see the progress being made.

If it looks like we’re going to need more credits than we estimated, we’ll let you know as soon as we’re able. In this scenario, you can either:

Purchase bonus credits for use within the sprint.

Do nothing, in which case development will simply pause once we’ve exceeded our allowance, resuming once the next sprint starts. In this scenario we always re-arrange the queue to make most effective use of the remaining credits.

If we finish all features in the sprint with credits to spare, we’ll start working on tasks from the backlog. It’s worth noting that unused credits do not carry over to the next sprint. To reduce the chances of this happening (working as efficiently as possible!) we always want to have enough features in the backlog that we can pull into the sprint if we’re able.

After a sprint

A sprint is three weeks long followed by one week for light feedback and planning for the next sprint. We won’t be doing any real development here, but instead catching our breath, reviewing what we’ve built, and figuring out what to build next. We’re effectively re-doing the

Planning a sprint⁠

step, just for the subsequent sprint.

Changing your plan

We ask for a minimum of two weeks notice for any plan change; this includes starting a new plan, moving to new plan with more or less capacity, or cancelling a plan.

Plan billing

Payment for subsequent sprints is due two weeks from the sprint’s start date.

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.