Team Practices Group/Scrum Estimation Meeting
This page is obsolete. It is being retained for archival purposes. It may document extensions or features that are obsolete and/or no longer supported. Do not rely on the information here being up-to-date.
This page is currently a draft.
- 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.
- 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).
- 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.
- 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.