The Life Cycle of a Canvas Mobile Feature Idea for iOS

[#1]

The Canvas Community does a great job in documenting the life cycle of new features for the web version of Canvas, but what about ideas for the mobile apps? In a "mobile world" where users expect quick and frequent changes, careful planning is still the cornerstone of creating features and updates that are reliable, full-featured, and timely.

To help the Canvas Community understand this process,  @KristinL ​ and I teamed up with iOS engineer Deactivated user​ to document the life cycle of a Canvas mobile idea for iOS. This includes an easy to following infographic and a longer description of the process below.

The Life Cycle of a Canvas Mobile idea for iOS

1. Product Idea - This could stem from Canvas product teams, Canvas community, contractual obligations, etc.
2. Documentation & Design - User Experience (UX) creates several different options for the ways the feature could look and function based on requirements documented by Product Management.
3. Validation - The Canvas Mobile Product Manager and UX designer travel to schools. During these visits, they could show mockups of designs and perform A/B tests to see which experience performs better.
4. Estimation - Once a path is chosen, engineers estimate out what the engineering time would take to build that. Occasionally engineering can push back saying that something is not possible or would be too costly, and it could loop back to #3.
5. Engineering - Every 2 weeks a meeting is held to plan tasks for the next 2 weeks. Once engineering has made it to that point in the backlog, work can be planned for a “sprint” in which it is assigned to an engineer. Each team has a “velocity” in which a number is assigned to how much each head can accomplish per sprint. Some features may span multiple sprints based on that number.
6. Prioritization - Once estimated, the product team prioritizes the feature in the backlog against other features and deadlines.
7. Build - When ready, an engineer pushes the code to a build machine, called a Continuous Integration Server (CI). The server will check the code, compile it into the application, and run the unit and automated tests. If everything checks out, it will give its stamp of approval on the patch.
8. Code review - Every line of code must be reviewed before it can be merged, for SOC2 compliance. Once an engineer wraps up a feature, that code gets pushed to another engineer’s hands, where they can review and double check for mistakes. The code may go back to the engineer’s hands, if something is found.
9. QA* - Each patch that passes code review is given to Quality Assurance (QA). QA checks out the build from the CI server and tests that change. There may be back and forth here between QA and Engineering as QA finds items that might have been missed by Engineering.
10. Merge* - Once the CI server, another engineer, and QA place their stamp of approval on the patch, it can be merged into the code repository.
11. Internal Beta* - Once all the items for a release are done, an internal beta build is compiled and sent to Apple for a quick review. QA will often perform a full regression test. If something is found, they will write up bugs from the findings and release is halted if needed.
12. Public Beta* - If new features are extensive we may create a public beta. In which time, we may push a build out through TestFlight, and a similar process is followed as if issues were found in the internal beta stage.
13. Release - Once the beta period has ended with no issues, the release candidate is pushed to Apple for review. Once approved the new feature is available to Canvas users.

*During steps 9-12, documentation, training, and marketing is developed.