Team Practices Group/Scrum Estimation Meeting


  • 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 forEdit

  • 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 EstimationEdit

  • 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 EstimationEdit

  • Pull up hatjitsu (or an alternative method for estimating/Poker Planning) and create a room:
  • 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 EstimationEdit

  • 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.