# Issue management and estimation --- 1. [A quick intro to managing software projects](https://hackmd.io/@fac/S1wGfV2M8#/) 2. **Issue management and estimation** 3. [The Build Sprint](https://hackmd.io/@fac/S1ZTP6UcI#/) 4. [A quick intro to product management](https://hackmd.io/@fac/BkJLkLxnr#/) 5. [The Design Sprint](https://hackmd.io/@fac/rySEBaUq8) --- Estimation is probably the most valuable skill you need to cultivate as a developer. --- ## RECAP - Scrum(TM) - User story - Backlog, project board - Product owner - Sprint, sprint backlog - Sprint planning, sprint review - Daily stand-up --- ## Some new definitions --- ### Estimate The difficulty level of a user story, expressed in *points* ---- #### CONTROVERSY ALERT Some people prefer to estimate in *absolute* time, expressed in hours or half-days, but in order to develop a good sense of *relative* time, for now we will estimate our user stories in *points* --- ### Velocity The team capacity, expressed in points, for each sprint --- ### Sprint backlog *new definition* A prioritised backlog of all the user stories that we estimate will be completed in the next sprint, *given each user story estimate and the team's velocity* --- ### Sprint review *new definition* Where the team compares their *points estimate of each user story with their actual points and adjusts their estimated velocity for the next sprint* --- ## RECAP - Scrum(TM) - User story - Backlog, project board - Product owner - Sprint, sprint backlog - Sprint planning, sprint review - Estimate *NEW* - Velocity *NEW* - Daily stand-up --- ### Note Not all issues raised in the project board contribute to the velocity estimate. **Chores**, **bugs**, **refactors** and **spikes** are all zero-point issues, even though they will (seriously) impact your sprint velocity. --- ### Zero-point issues - **Chore** Something that needs to be done, not directly related to a user story - **Bug** Something broken - **Refactor** An improvement to the code that delivers no change to user experience - **Spike** Researching a potential solution to a problem by creating the simplest possible implementation of it ---- #### CONTROVERSY ALERT Some people prefer to estimate chores, bugs, refactors and spikes just like user stories. The argument for making them zero-point issues is to emphasise that they are *non-negotiable* and therefore outside the scope of the sprint planning process. --- ## Labels To be added to issues --- ### Status labels - `backlog` - `stretch` - `todo` - `doing` - `done` --- ### Issue-type labels - `story` - `chore` - `bug` - `refactor` - `spike` ---- ### Estimate labels - `E1` - Short story, estimated - `E2` - Story, estimated - `E3` - Long story, estimated - `E5` - Extra long story, estimated --- ### Actual labels - `A1` - Short story, actual - `A2` - Story, actual - `A3` - Long story, actual - `A5` - Extra long story, actual --- ## Using estimation labels --- ### First sprint planning session ever - Move user stories that you want to complete this sprint into your sprint backlog; - Go through each user story and agree estimates for all of them as a team; - Adjust the number of stories in the backlog until everyone is happy the number is realistic; - Count up the points in your user stories: this is your **first estimated sprint velocity**. --- ### Every sprint review Count the actual number of user story points completed in the latest sprint. This is your **new estimated sprint velocity**. --- ### Subsequent sprint planning sessions - Move user stories into your sprint backlog and (re-)estimate all of them as a team; - ***NEW*** Adjust your estimated sprint velocity, based on expected team availability; - ***NEW*** Adjust the number of user stories in the Sprint backlog until the total points estimate is equal to your estimated sprint velocity. --- Repeat... --- Every time you go through the sprint planning process, expect your estimates to get better. --- ## Presentations - Report on estimated vs actual velocity - And don't forget to show your project board --- ## Final thought: Hofstadter's Law It always takes longer than you expect, even when you take into account Hofstadter's Law. --- 3. [The Build Sprint](https://hackmd.io/@fac/S1ZTP6UcI#/)