Revision as of 20:31, 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.

Break down project into small tasks

So you should be able to tell the dev cost of all your features and thus your project
Over time, your team will be more accurate on points estimatio.

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 34: / Line 34: @@
 <div class="mw-collapsible-content">
 * A sprint is a basic development cycle, make sure sprint is not too big, for example, 2 weeks per sprint is a common choice.
+</div>
+</div>
+<p></p>
+<div class="toccolours mw-collapsible mw-collapsed expandable">
+<div class="mw-collapsible-preview">Break down project into small tasks</div>
+<div class="mw-collapsible-content">
+* Eash task should be small enough to fit into a single sprint
+* You should assign points to each task
+<hr/>
+* So you should be able to tell the dev cost of all your features and thus your project
+* Over time, your team will be more accurate on points estimatio.
 </div>
 </div>