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.

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.

This article is issued from Mediawiki. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.