Revision as of 20:28, 23 March 2023

Goal

Feature Development Speed Is Predictable

You know how many points your team can finish per sprint.
Usually you have 1 primary and 1 backup on-call engineer.
- This allows other engineers to make progress on feature work at full speed
- The rotation of the on-call gives every engineer an opportunity to get familiar your product.

Fast Evolving: Quick Response To Market Condition Change

You can adjust priority frequently at sprint level to respond to market condition changes.

More Checkpoint to Avoid Big Mistakes

Since you have checkpoint at every sprint, in case anything goes wrong, it should be caught quickly.

Define Sprint

A sprint is a basic development cycle, make sure sprint is not too big, for example, 2 weeks per sprint is a common choice.

Have scrum on a regular basis

A good practice is to have daily scrum
Go through devop issues during scrum.
Go through the team and ask everyone:
- Are you on track for assigned tasks?
- Any blockers?

@@ Line 7: / Line 7: @@
 * You know how many points your team can finish per sprint.
 * Usually you have 1 primary and 1 backup on-call engineer.
-** This allows other engineers can make progress at full speed
+** This allows other engineers to make progress on feature work at full speed
 ** The rotation of the on-call gives every engineer an opportunity to get familiar your product.
 </div>
@@ Line 16: / Line 16: @@
 <div class="mw-collapsible-preview">Fast Evolving: Quick Response To Market Condition Change</div>
 <div class="mw-collapsible-content">
-* You can adjust priority frequently at sprint level to response to market condition change.
+* You can adjust priority frequently at sprint level to respond to market condition changes.
 </div>
 </div>