Independently of the actual development process, which also changes over time, in whatever we do, we always do it with a team-first mindset. For teams to work, team members should put the needs of the team above their own. They should:

• Arrive for stand-ups and meetings on time
• Keep discussions and investigations on track
• Encourage focus on team goals
• Help unblock other team members before starting on new work
• Mentor new or less experienced team members
• Avoid "winning" arguments, and, instead, agree to explore options

Feature iteration and scoping

• We continuously prepare new features for development, and in this process it’s very important to keep everyone involved so we can share insight from multiple perspectives
• We do this by regularly scheduling Design briefs (insert better name), where the designers briefs the rest of the team on upcoming features, and the rest of the the team gets to share their insight. This could be anything from feedback on the suggested solutions, additional features they think would be nice to include, etc
• We also have scheduled backlog grooming sessions every week where we go together through the upcoming priorities, explain why we are doing certain things, raise questions, scope the work further if needed and even estimate it if we are ready to do so
• When we’ve iterated the features to a state where they make sense for both designers and developers, the tech lead and developers with the most relevant experience get together to discuss solutions and scope complexity
  • This doesn’t mean that we don’t want everyone's input if they would have solved it differently or scoped it differently

<aside> 💡 On scoping… When it’s Okay to Cut Scope: • When you can maintain a minimum viable product, still deliver value, and still capitalize on the business opportunity • When the cost of additional features/functionality outweighs the benefit of getting them built • When you can ensure that "fast follow" work can be done

When it’s Not Okay to Cut Scope: • When reducing scope means you are chipping away at the core value of the product/feature  • When you can't ensure that "fast follow" work can be done

</aside>

Sprints

• A sprint lasts two weeks
• The team needs to plan and align on the goal for the sprint before starting it. At the end of the sprint planning, we set our main Sprint Goal, which acts as a compass during the sprint to help us make decisions if changes happen.
• Ideally, no new stories should be added to the sprint after it’s started
• Inside a sprint, we should focus on completing, testing and iterating features as fast as possible. This means we should submit to test flight as often as possible and ask product for feedback/approval throughout a sprint, and not wait until the end of the sprint
• At the end of each sprint, we will have a show and tell + retro, to share insight, wisdom and reflections on what went great and what didn’t go so well

Releases