Team Practices Group/Scrum Estimation Meeting

Purpose

 * Review fleshed out work and determine the relative story points for that work OR send work back to the backlog for grooming.
 * Create expectations around how challenging or uncertain specific tasks are in order to better forecast sprints long-term (release planning, if applicable).
 * Get a sense of how much the team can plan and commit to in a sprint by using historical velocity.
 * Estimation is an opportunity to get clarity around work ("why do you think this is 5 story points and he thinks this is 1 story point?").
 * This can also reveal gaps in skills and create opportunities for more collective ownership.
 * Estimation can drive prioritization (low-hanging fruit might change prioritization, for example).
 * A way for teams to understand and track their work (in a proprietary way).
 * Helps keep accurate trends of the team's ability to compete its work.
 * Team commits to the plan.

What it's not for

 * A way to measure or judge the team's success.
 * A place to measure or judge an individual's ability to complete the work.
 * Discussing work we can't do (it should be "estimatable").
 * Talking about process (the Spring Retrospective is for this).
 * Taking deep technical dives (unless critical for estimation) or start discussing implementation or start doing the work.
 * Prioritizing work (should be done at story prioritization meeting and asynchronously by Product Owner).
 * Estimations are not predictions, but a way to gauge anticipated capacity, with the understanding that the estimators are probably always wrong.

Before Estimation

 * Check in on story candidates before next planning meeting (estimation) to see if things are on their way to being ready (e.g. followup with owners of tasks that needed clarification); if not, leave a task management (Phab) comment or check in with responsible party.
 * Be aware of anything that has entered the queue since the prioritization meeting and follow-up with the PO and/or whoever added work to make sure the work is indeed ready to estimate.
 * Check in on team velocity to determine how many points the team can plan.
 * Note absences and holidays and any other commitments that fall within the upcoming sprint in order to calibrate team commitment/plan.
 * Pull up project backlog and sprint boards (current and upcoming).

During Estimation

 * Pull up hatjitsu (or an alternative method for estimating/Poker Planning) and create a room: http://hatjitsu.wmflabs.org
 * Evaluate what is likely to get pulled into the upcoming sprint from the current sprint.
 * Pull in high priority items if needed and OKed by PO.
 * Pull up relevant board/column and start by estimating the top item in the list.
 * State the name of the story.
 * The PO should describe the task in their own words (high-level view).
 * The team should to review the task.
 * Ask if there are any questions.
 * After questions, can the task be estimated?
 * If yes, "take it to the hatjitsu" (make sure hatjitsu board is cleared from any previous estimating): estimate.
 * Review the estimate if disparate and facilitate discussion until there is agreement.
 * Repeat until team has hit capacity.
 * After each task is estimated, tag it with the upcoming sprint project.
 * Ask the team to review the plan and make sure they are comfortable committing to it.

After Estimation

 * Check in at standup on Monday to see of there is any lingering work from previous sprint and re-coordinate plan as necessary w/PO and team.