How do I handle sprints at Cheerioai.com as CTO?

Sprint planning and streamlining the sprint process are paramount tasks in a startup. Key objectives include efficiently managing resources, accelerating time to market, and fostering adaptability. Clear planning aligns the team, ensures product quality, and mitigates risks, enhancing investor confidence and maximizing the startup's chances of success in a competitive landscape.

Here is an overview of the process we use at Cheerio:

Having a backlog and discovery list

We have a list of features in backlog or need some RnD. Sales and Product teams add feature requests in the section. After shortlisting the features, we start with the documentation process.

Steps followed while writing a Product Requirement Document (PRD)

• Feature description is written by the product team.

• A "planning meeting" is held between the development team, product team and QA team.

• Designs are added to the PRD by the designer assigned to the feature.

• Product spec. is written by the developers assigned to the feature. The "spec" provides execution-level details of how the requirements are going to be implemented.

• QA adds test cases to the PRD. The product team and development team review the test cases.

• If the feature is big enough, it is broken down into smaller parts.

• Hours/Story points(SP) are assigned to every task in the feature. Separate SPs are assigned for testing by devs and QA respectively.

• Developers are asked for updates on every standup

• Once the development is over. The developer passes all the test cases locally.

• The feature is sent for review by raising a PR. The tech lead reviews the code and merges the code once they are satisfied.

• Developers and QA pass the test cases on dev.

• Code is pushed to the Staging environment.

• QA passes the test cases on the staging environment.

• Final testing is done by me before sending the feature to Production.

• Regression tests are performed on Production along with sanity tests by the QA team.

Retrospective

• Bugs are tracked and assigned to developers.

• RCA is written by developers for repeated bugs.

• Tech Review is performed every alternate week after the completion of every sprint.

• Burndown charts are referred to keep track of the sprint and productivity of the developers.