Development Process

While building our engineering team, we have focussed on hiring competent individuals who can carry complete epics from start to finish.

As such, each team member can execute on their assigned epic mostly autonomously. The structure and meetings we have put in place are meant to be touch points for collaboration to ensure we can act as a sounding board for one another, quickly work through blockers and align on direction whenever necessary.

🔔 You can find the templates into the templates section of this Doc.

Epics

Epics are comprised of one holistic improvement to the product. This may be one significant feature or several small ones that create a complete experience.

Epics have three separate owners.

• The product owns the "why and when."
• Design owns the "what"
• Engineering owns the "how"

Our responsibility within engineering is to provide the "how" and execute that "how.” That said, it is crucial to understand that there is a need for strong collaboration between these three owners to arrive at the best of each (why, what, and how).

To the engineering owner:

As an engineer on the team, you will be responsible for implementing the complete epic from top to bottom and delivering that epic to production. Once you have taken ownership of an epic, it is your responsibility.

• You should work directly with design and product to understand the epic's reasoning and the proposed solution's details.
• You will be responsible for assessing the proposed implementation and identifying technical holes in the feasibility of the implementation. You should resolve these with design as quickly as possible to arrive at a feasible implementation.
• You will then be expected to not only define how it will be implemented but also to layout the technical plan and iterative steps for how to get there.
• You should document the technical planning so that others can understand it and solicit feedback to align it with the overall technical direction.
• You will be expected to layout your sprint board with the exact work you plan to accomplish for each sprint.
• You will be responsible for implementing all of the code associated with the epic.
• You will be responsible for delivering the epic to production, including laying out any release steps necessary for deploying that epic and executing the actual deployment.

Sprints

Our sprints are setup to be one week long. At the end of a sprint, the objective should be to deliver something internally releasable that can be shown to users for testing during user interviews. This enables us to get early product feedback and helps resolve issues and make adjustments sooner rather than later during an epic.

Timeline

🚨This can be adjusted as needed, but this is the general timeline we should aim for.

Monday (pre-sprint)

• Work with the product to identify precisely what will be worked on during the next sprint (this is a collaborative process and more about getting alignment on what makes sense to bite off that can actually be delivered to users in testing)
• Prepare technical plans for sprint planning the following day.
• Review technical plans with teams during the technical review meeting.

Tuesday (start of sprint)

• Align with the product on what can be accomplished for the week during the sprint planning meeting
• Start sprint execution

Wednesday

• check-in on progress during the standup meeting

Thursday

• check-in on progress during the standup meeting

Friday

• check-in on progress during the standup meeting

Monday (end of the sprint)

• Check-in on progress during the standup meeting
• Complete sprint tasks
• Shoot sprint review
• Release to staging
• Plan for next sprint

Meetings

We try maintaining a meeting light culture and doing more async than synchronous. That said, we also understand the importance of synchronous meetings for team bonding and socializing.

Technical planning review

This meeting is a chance for engineering to align on technical implementation. We each are responsible for our own epics and work autonomously. However, this can make it more difficult to align in an overall technical direction from a higher-level perspective. We should use this meeting to agree on those technical directions. We should also use this meeting as a chance to help the team uncover possible unknowns we may have missed during our individual planning.

Sprint planning

This is our opportunity to sync with the product and align on what will be delivered at the end of the sprint. We should aim to deliver something users can test at the end of each sprint.

Daily standup

This is an opportunity for the entire team to sync with one another. We each check in on progress and hold ourselves accountable for our own progress that we committed to the previous day.

• Add items to your todo list before the meeting starts
• Items add should be based on impact, not busy work
• I plan to complete X (not I plan to continue on X)
• Add any items to blockers
• Anything that prevented you from completing your objectives the day before that the team could help you with
• Add any items where someone else could help you do your best work