How to Conduct an Agile Story Sizing Meeting

Agile Construction Team
As I discussed in my last post (Three Agile Insights working with Offshore Teams), I spent the last several days visiting offshore development teams and had the occasion of observing one team performing an Agile Sizing meeting. Sizing is a critical task performed by agile teams and the process attempts to put an estimate on the cost, complexity and risk of a Story prioritized in the backlog. The sizing serves a number of purposes
  • Developing the metric is a mechanism for individuals to share their understanding of the requirement, ask questions, and to discuss any complexities with the implementation.
  • It provides feedback to the product owner, architects, and stakeholders on the overall complexity of the Story. If a story is sized high, it may cause one to challenge the priority of the story or provide grounds to question the team on approach.


Conducting a Sizing Meeting

The journey is more important than the result. This meeting serves a greater purpose than just getting a number on a Story - it's a mechanism for teams to collaborate and challenge each other. Teams that overly rely on planning poker and other mechanical tools to vote on Story Sizes may miss out on an important team dynamic. So while observing one team I truly appreciated how it managed this meeting.
  • The backlog was displayed on a large monitor for all teams to see.
  • Remote team members participated including QA.
  • The Lead (tech lead on our teams, ScrumMaster may be appropriate for others) read the story.
  • The Lead called out each person on the team to relay their thinking of the story and to announce and justify the size.
  • The Lead decided on the final size - often taking the maximum set by team members. Stories that could not be sized or where there was too much variance by individuals were not sized.
  • The story was updated with the agreed on size in the backlog.
  • The meeting was conducted efficiently going from one story to the next until all stories ready for sizing were reviewed.
What I appreciated most was the dialog that led to either a shared understanding or questions that needed clarification. The meeting had a fast rhythm to it, driven by the Lead, insuring that each team member was called upon to speak. The rhythm forced individuals to be specific and concise on declaring their story size and rationale.

Valuable, efficient, and productive.

Note that in the Agile practices I sponsor, Sizing is a distinct and separate process than Estimation as you can see from my earlier post on How and Why to Estimate in Agile. I'll connect these two processes in my next post.


  1. Hi, Neat post. There’s a problem along with your web site in web explorer, might check this… IE still is the market leader and a good component to folks will pass over your excellent writing because of this problem.
    hollywood venues

  2. Thanks for this wonderful sharing during agile projects the development team, the product owner, and the scrum master work closely together on a daily basis. Daily scrum meetings let the development team organize around work completed, future work, and roadblocks. During sprint reviews the development team can demonstrate and discuss the product directly with stakeholders.

  3. This is the way how it grows because i have personally experienced this and it works most of the times.Right now there is a need of going to the next level and that works if done in the right manner, agile business is perfect in terms of the growth.


Comments on this blog are moderated and we do not accept comments that have links to other websites.