[Plan] Standard Development Process

[xoscar]

Writing an Epic

Creating epic has become a way for the team to group a bunch of work that needs to be completed in order to reach a specific goal, but we don't have a clear standard on how to write them and what information belongs in the epic.

Let's define what we want to achieve with an epic:

• Have a clear common goal, everyone understands what and why are we working on this
• Provide visibility, anyone inside or outside the team could clearly understand the state of the epic, what is left, and how to contribute
• Defining requirements, an epic should be a conceptual understanding of the stakeholder's requirements
• Allowing flexibility, if work needs to be added and/or removed that should be entirely possible
• Divide the work into smaller tasks, allowing splitting the work
• Encourage conversation, as it should only focus on the what and why, it should allow teams to collaborate in the how part
• Define scope, it should allow the team to have a clear understanding of the number of features, changes, etc
• Clarify priority, what needs to be done before what, and identify possible dependencies

Now, let's talk about tasks:

• Tasks should contain enough details, either linked or directly in the description, for any team member to work on them
• Team members should be able to further down breakdown the tasks into smaller parts depending on the required technical implementation
• Technical details and the how can be discussed as part of each task and/or defined during grooming

Where to technical details? Technical details like architectural designs, how-tos, or other things like that, should be defined in outside sources, scoped to specific tasks, or part of epics discussions/comments. But always linked back to tasks that can be easily found by team members.

What is the final goal of all of this?

1. Everyone shares the same vision of the project(s)
2. Team members have clarity on what work needs to be done and how to prioritize tasks
3. The work is defined in a way where the context and info are spread to avoid one person doing everything
4. Having a clear line of requirements, top to bottom
5. Allowing the technical team to understand the full scope/goal of the project and focus on the hows after that
6. Provide visibility on the project's progress

Calls, planning, grooming

Ideally, we want to aim to have efficient meetings, with clear agendas and time-boxed to not go over time. This is to encourage the following dynamics:

1. Prefer async communication
2. Avoid unnecessary meetings
3. Remove distractions and have more focus time
4. Self-management of time

Branching, Development, Releases

This is still a work in process, but here are some of the goals:

1. Be always safe to merge into the main banch
2. Prefer feature flags, merging to main than long-living branches
3. Automate the rollback process
4. Usage of the release checklist
5. Introduction of Gitflow or Trunk based development
6. Have a defined release cadence

[xoscar]

https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow https://www.atlassian.com/continuous-delivery/continuous-integration/trunk-based-development

[xoscar]

• Templates to ensure consistency when writing epics

• Using discussions as starting points for epics or opening a discussion per epic

• The description of the epic should explain the goal

• Organized async communication (avoid buzz noise)

• Find a balance between async communication and meetings

• Make non-critical meetings optional

• Define versioning for weekly releases