Team Practices Group/Scrum Estimation Meeting

The Team Practices Group (TPG) was dissolved in 2017.

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.