Processes

Juiced uses 2 waterfall processes to add or fix features.

Add

Suggest = a user, 3rd party, or an internal party may suggest a new feature.
Suggest review = a suggestion that has received a high amount of upvotes or demand will be reviewed by the CTO, CFO, CEO, and CPO.
Requirements = if a suggestion is approved, the CTO and CPO will update our documentation to provide instructions on what is required.
Design = once the requirements are set, the designer will begin the design.
Design review = upon completing the design, the design will be reviewed by the CPO and other people involved with the feature.
Code = once the design is approved, the developers will begin coding.
Code review = once the code is written, the CTO will review the code and make sure the code has been written in line with our build standards.
Testing = once the code has been approved, the quality assurance developer will run thorough tests on a test app.
Final review = finally, once the code has been reviewed and the QA has done the tests, the CPO will do a final review.
Partial roll-out = after the first 9 stages, the feature should be rolled out to a batch of users based on a relative cohort. For example, you can do regional role-outs, interest-based role-outs, etc.
Full roll-out = once the partial roll-out has been successful for over 2 weeks without any complaints or bugs, a full roll-out can happen, making the feature available to all users.
Maintenance = shortly after the full roll-out, maintenance efforts should be put in place.

Fix

Report = a user, 3rd party, or an internal party may report a bug. --- OR ---
Detect = ai or automation will detect potential flaws, outages, or bugs.
Identify = within 1-2 hours of detection or reports of issues, developers need to identify the cause of the issue.
Patch = once the issue is identified, within 30 minutes the bug will need to be patched.
Test = upon patching the issue, a test should be performed to see if any other issues have come up as a result of the patch or if any other issues are active as a result of the identified cause.

PreviousTable of contents NextTechnology / services

Last updated 3 years ago

Was this helpful?

Juiced uses 2 waterfall processes to add or fix features.

Add

Suggest = a user, 3rd party, or an internal party may suggest a new feature.

Suggest review = a suggestion that has received a high amount of upvotes or demand will be reviewed by the CTO, CFO, CEO, and CPO.

Requirements = if a suggestion is approved, the CTO and CPO will update our documentation to provide instructions on what is required.

Design = once the requirements are set, the designer will begin the design.

Design review = upon completing the design, the design will be reviewed by the CPO and other people involved with the feature.

Code = once the design is approved, the developers will begin coding.

Code review = once the code is written, the CTO will review the code and make sure the code has been written in line with our build standards.

Testing = once the code has been approved, the quality assurance developer will run thorough tests on a test app.

Final review = finally, once the code has been reviewed and the QA has done the tests, the CPO will do a final review.

Partial roll-out = after the first 9 stages, the feature should be rolled out to a batch of users based on a relative cohort. For example, you can do regional role-outs, interest-based role-outs, etc.

Full roll-out = once the partial roll-out has been successful for over 2 weeks without any complaints or bugs, a full roll-out can happen, making the feature available to all users.

Maintenance = shortly after the full roll-out, maintenance efforts should be put in place.

Fix

Report = a user, 3rd party, or an internal party may report a bug. --- OR ---

Detect = ai or automation will detect potential flaws, outages, or bugs.

Identify = within 1-2 hours of detection or reports of issues, developers need to identify the cause of the issue.

Patch = once the issue is identified, within 30 minutes the bug will need to be patched.

Test = upon patching the issue, a test should be performed to see if any other issues have come up as a result of the patch or if any other issues are active as a result of the identified cause.