How to Conduct an Agile Story Sizing Meeting

2013_02_05_0669
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.

5 comments:

  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

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

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

    ReplyDelete
  4. Hello there, thanks for the article and every company kind of improvise a bit for all the events in agile.
    I wanted to know if the ticket subtask to be worked on Development and development task is to be discussed during sizing ?

    ReplyDelete
  5. I've seen subtask creation and assignment work differently by agile team.

    * Some will not do task breakdown, or only do it where the story has some complexity or multiple people working on it.
    * If it's technical complexity, it should be done before or during sizing as the size of the story reflects this complexity.
    * If the story isn't tech complex and the subtasks just make it clear who's doing what, then that can be done later after sizing.For example, when the team discusses it in Standup and moves the Story to In Progress, then that would be a good time to discuss any individual assignments.

    ReplyDelete

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

Share