# Sprint Backlog > backlog is stories that are not ready, in-progress, or farther down the chain > I.E. things we're not working on **YET** - We perform a backlog meeting to: - Prevent making a junk drawer out of the pile - Prioritize/queue items for the next sprint - Dust the cobwebs: - Re-class/Retire items not for the next Sprint - backlog is to get stories made even if just placeholders set up in time for the Wednesday sprint planning/retro. # Sprint Planning - This is a confirmation meeting of what we will be working on over the next 2 weeks - Planned work is prioritized with the `P` tags and is structured & prioritized *See [[#Priority]]* - You need to plan to have a buffer during the sprint and your planned work for: - Potentially unplanned work - When others need your expertise - This is when communication of peer reviewers is helpful to plan for This - You can always go for a stretch goal down the line - but don't bite off more than you can feasibly chew # Sprint Performance - During the sprint there will be a Retrospective board to review later during the Retrospective - fill out any relevant information about the sprint live while it is fresh and top of mind - Document your steps, roadblocks, process, and deliverables in your stories - They are a record of what you did so we have referencial institutional knowledge # Sprint Retrospective - End of the Sprint what ever i can't complete and put into peer review get moved into the next sprint for completion - then i should re-do the `P` tags and prep for the next sprint iteration - We review the Retrospective Board for things that went well or didn't go well, could be done better, more of, less of etc. - Process driver not person specific, it's not about blame it's about making the system stronger, and more robust # Details ## Work Item Breakdowns ### Epics - Epics are big projects/goals and can span multiple sprints^[[[#Iterations]]] - `state`: new always - `iteration`: What sprint did this originate in (items can be carried forward into new sprints) - `area`: something we can do to assign work to different initiatives - No More than 3 epics at a time being worked on - Epics shouldn't last longer than **2 months** the way we currently use them - [[#Stories]] and Epics - `Descriptions`: _"As a/an: \_\_\_\_\_ I'd like: \_\_\_\_\_ So that I can: \_\_\_\_\_"_ - `Acceptance Criteria`: To accept that this work is complete, what needs to happen? - An approved deliverable? - Creation of a service? - Correction of a bug? - `Comments`: Use these as a log of your work, roadblocks, steps taken, deliverables, etc. - These are a living record of your work for others to reference - `Naming Convention`: Epics start with `[OPS] IT-Data: ` - Provided they are an `[OPS]` related Epic - `IT-Data: ` is the Data Team's tag in the title - `Tags`: Both [[#Stories]] and Epics get [[#Tags]] - See [[#Tags]] - `Relationships`: [[#Stories]] are children of Epics and get linked as children to them - [[#Stories]] not linked to an Epic are likely `P#` unplanned work ### Features - we currently do not use these ### Stories - Stories are what comprises the Epic - Units of work - 4-24 hours of work per story - Spikes are Research Stories ### Tasks - we currently do not use these ## Tags - `OPS` - Operations - `IT` - Information Technology - `On Deck` - denotes things that were intentionally pulled into the sprint. [[#Stories]] that were pulled in outside of the normal process. - `Documentation` - - `SQL` - Structured Query Language Work - `GIS` - Graphical Information Systems Work - [x] `Revisit` ## Priority - There should only be 1 priority tag per card and each tag should be unique amongst each team member - i.e. i only have 1 story with `P1` and 1 with `P2` there should not be a second story with a `P1` or `P2` in this instance unless its a carry over from the last sprint - Unplanned work is denoted with `P#` and is what we want to try and avoid - Breaks the planned priorities of the sprint - If I start seeing a trend of P# stories in the sprint from the entire team that means that: - Something catastrophic happened and we need to do a RCA (root cause analysis) to make sure it never happens again - We planned incredibly poorly for the sprint - We didn't plan at all for sprint (see above) - If I start seeing a trend of P# stories in the sprint from single people on the team, this could mean that: - Someone is intentionally breaking the sprint - For relationship reasons (high-profile customer) - They can't say no (training and support issue) ## Ownership - [[#Epics]] and [[#Stories]] should only ever have 1 owner - Ownership can change during the review processes but ultimately returns to the originator - this makes it so when the card is completed "credit" goes to the person doing the work on it and not others who close out cards during review processes like the PO in `PO Review` otherwise it looks like project owner is the only one getting any work done ## Swim lanes - `Not Queued` - Items not queued for the current sprint - `Ready` - Things queued up for the current sprint - They have been tagged with priority tags - We hope to accomplish all of them this sprint iteration - They are ready and they are currently not being worked on - `In Progress` - The items you are currently working on right now - `Ready for peer Review` - Items that are ready for peer review - The discussion for who should peer review should take place during sprint planning. This way, everyone on the team goes into the next sprint knowing: - What work they plan to pull into the sprint - What work they'll be reviewing in the sprint - Some kind of idea of their total capacity to do work during the sprint vs. work planned for the sprint (which includes review work - peer, customer, PO) - Once peer is ready, move card to this lane and assign it to them - `Peer Review` - The peer has reviewed the work and moved it to this lane - The work item has ownership re-assigned back to you - You can now work on any revisions - `Ready for customer Review` - Items that are ready for customer review - `Customer Review` - The work item has ownership re-assigned back to you - You can now work on any revisions - `Ready for PO Review` - Items that are ready for PO^[Project Owner] review - At this point you're basically done with it - `PO Review` - - `Done` - Completed work ## Iterations - Sprints are currently 2 week Iterations Start/Stopping on Wednesdays - when you complete all your work for the current iteration you can move forward with a Stretch goal - Stretch goals are a good thing - This means that you've finished all your planned work - and are able to take on additional work