Dl/sprint: Difference between revisions
From stonehomewiki
Jump to navigationJump to search
Stonezhong (talk | contribs) (→How) |
Stonezhong (talk | contribs) (→How) |
||
| (3 intermediate revisions by the same user not shown) | |||
| Line 5: | Line 5: | ||
<div class="mw-collapsible-preview">Feature Development Speed Is Predictable</div> | <div class="mw-collapsible-preview">Feature Development Speed Is Predictable</div> | ||
<div class="mw-collapsible-content"> | <div class="mw-collapsible-content"> | ||
* 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. | |||
</div> | </div> | ||
</div> | </div> | ||
| Line 12: | Line 16: | ||
<div class="mw-collapsible-preview">Fast Evolving: Quick Response To Market Condition Change</div> | <div class="mw-collapsible-preview">Fast Evolving: Quick Response To Market Condition Change</div> | ||
<div class="mw-collapsible-content"> | <div class="mw-collapsible-content"> | ||
* You can adjust priority frequently at sprint level to respond to market condition changes. | |||
</div> | </div> | ||
</div> | </div> | ||
| Line 19: | Line 24: | ||
<div class="mw-collapsible-preview">More Checkpoint to Avoid Big Mistakes</div> | <div class="mw-collapsible-preview">More Checkpoint to Avoid Big Mistakes</div> | ||
<div class="mw-collapsible-content"> | <div class="mw-collapsible-content"> | ||
* Since you have checkpoint at every sprint, in case anything goes wrong, it should be caught quickly. | |||
</div> | </div> | ||
</div> | </div> | ||
| Line 28: | Line 34: | ||
<div class="mw-collapsible-content"> | <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. | * 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> | ||
</div> | </div> | ||
| Line 40: | Line 58: | ||
** Are you on track for assigned tasks? | ** Are you on track for assigned tasks? | ||
** Any blockers? | ** Any blockers? | ||
</div> | |||
</div> | |||
<p></p> | |||
<div class="toccolours mw-collapsible mw-collapsed expandable"> | |||
<div class="mw-collapsible-preview">Sprint Retrospect</div> | |||
<div class="mw-collapsible-content"> | |||
Once a sprint is done, it is good idea to have retrospect which covers: | |||
* What practices should the team continue? | |||
* What practices should the team stop? | |||
</div> | </div> | ||
</div> | </div> | ||
<p></p> | <p></p> | ||