Story Sizing Workshop

A story point is an abstract measure of effort required to implement a user story. In simple terms, it is a number that tells the team about the difficulty level of the story. Difficulty could be related to complexities, risks, and efforts involved.

In most cases a story point uses one of the following scales for sizing:

• T-shirt Sizing: X-Small, Small, Medium, Large, Extra-Large
• Fibonacci sequence: 1,2,3,5,8,13,21

However, it is tough to identify a story from the scales assigned to them. In order to do that each team would have to find a baseline story. It does not necessarily to be the smallest one, but the one that everyone within the team can resonate with. Once determined, sizing of all the user stories should be initiated by comparing them against the baseline.

While estimating story points, we assign a point value to each story. Relative values are more important than the raw values. A story that is assigned 2 story points should be twice as much as a story that is assigned 1 story point. It should also be two-thirds of a story that is estimated 3 story points. How do we determine a story is twice is large as another?

Here’s where the workshop comes into play. As a Team, talk through and establish what is low/medium/high risk, complexity and uncertainty means for your team and what is small/medium/large knowledge, volume and effort (no team is the same).

This is a great opportunity for more experienced Team members and newer Team members to talk through the work and get a better understanding of the type of work this is done. Non-software and software Teams alike that do this type of workshop.

This will guide the team to a baseline for sizing with pointing poker.

Teams should determine the matrix through discussion and using planning/pointing poker method. The facilitator guides the Team to establish a "point" for a low and a small. Then establish a low and a medium, low and large. Followed by a small and a medium, small and high...etc. until the matrix is filled out.

There may be some debate as to what determines a 2/3, or 3/5, or 8/13 (as example) or you can use the example (below) as your baseline since you already discussed what low/medium/high risk, complexity and uncertainty means for your team and what is small/medium/large knowledge, volume and effort.

Now that you have established the baseline criteria for your stories and points, when you refine the stories and point them as a team, you have a reference point to spark discussions if there is point discrepancy between Team members.

As the team matures, they can redefine what points look like to the Team and point because more familiar. Also remember we do this workshop as a team to increase accuracy by including all perspectives, build a better understanding of the work and creates a shared commitment.

Agile Teams often use estimating poker, which combines expert opinion, analogy, and disaggregation to create quick but reliable estimates.

Planning Poker is a consensus-based estimating technique. Agile teams around use Planning Poker to estimate their product backlogs.

The real value of estimating poker is to come to an agreement on the scope of a story. It’s also fun!

• Participants include all Team members
• The PO participates but does not estimate
• The Scrum Master participates but does not estimate, unless they are doing work as a Team Member
• Product Owner reads the description of the story
• Questions are asked and answered
• Each estimator privately selects an estimating card representing his or her estimate
• All cards are turned over at the same time to avoid bias and to make all estimates visible
• Discuss differences
• Re-estimate