Relative Sizing — User Story Estimation

Whenever I join a team or build a new team, Relative estimation becomes one of the topics of discussion. Hence this is my effort to explain it in simple terms. I hope it helps a wide audience.

Also posting a few commonly asked questions for the experts to answer. I understand answers will differ based on situations and can only give very generic answers/guidelines.

In general , Estimation

• is done before the start of the project
• is an information , NOT a confirmation

Relative Estimation

Relative estimation is all about comparing User Stories based on difficulty level( to develop)

Factors that could influence the difficulty level of User Story are

• Complexity
• Risks
• Efforts
• Dependency (with other Stories/systems etc)
• Unknowns

Commonly practiced way of relative estimation of User Stories is by assigning a Size based on the difficulty level. User Story with higher difficulty level will be assigned a higher Size.

Fibonacci series (1, 2, 3, 5, 8, 13, ..) often used to represent a Size. Please note that the actual Size is unimportant , what matters is the relative values( ratio between these Sizes).

In short we are grouping the User Stories in one of the buckets based on its size.

How is User Story Sizing done in Agile Projects

1. Product Owner brings a User Story and discuss with Dev team
2. Once understood , each Developer does sizing of story privately (Poker )
3. Developers discuss reasons/assumptions of Size suggested.

3rd Step usually done when Size values differ. This is also a very important step which helps to

• Develop a common understanding of the requirement
• Validate no one misunderstood the requirement

Advantages

• Faster — ( Humans are faster in comparing )
• Easy to explain to others
• Team centric than individual specific ( entire team is part of sizing)

Establishing a Baseline

For a new Scrum team it is a good practice to find a baseline size based on one User Story. This User Story will be referenced for sizing the rest of the User Stories. Over a time period ( after 5 Sprints or so ) all developers will develop a common understanding/agreement on sizing regardless of their skills/competencies.

FAQ:

1. Should we resize a non-done story before moving to the next Sprint?
2. Should PO participate in sizing?
3. Why is it important for all Dev members to be involved in sizing ?
4. Should we Size for UI, Backend & QA separately and add all up ?