Estimation

41 prog-estimation

Story point estimation is a proven technique that allows teams to quickly estimate work in a relative fashion, and it’s a prerequisite for accurate Program and Team segment planning.

Explore More.

Related Mindset:

Lean-Agile

Segment:

Program

Inputs:

Unestimated user stories with clearly defined acceptance criteria

Outputs:

User stories with story point estimates

Relative estimation using story points on user stories is a proven element of agile development.

User stories are the primary mechanism for defining intended system behavior in Lean-Agile organizations.1 They are the most granular unit of work typically estimated by teams for planning purposes, and they are most often estimated using story points.

A story point is an arbitrary measure of effort that represents the team’s assessment of how long it will take to implement a story relative to other stories.2 A modified Fibonacci scale – 1, 2, 3, 5, 8, 13, 20, 40 – is often used to rank one story’s level of effort against another. For example, a 1-point story is expected to take half the time for the team to implement as a 2-point story.

Planning Poker is one common technique used by teams to estimating user stories in their backlog.3 In a Planning Poker session, a team discusses each user story and familiarizes themselves with requirements and acceptance criteria. Each estimator then privately selects a card marked with the story point value that they believe represents the appropriate level of effort for the story. The team then reveals all cards at the same time. If there is consensus on a story’s effort, that estimate is assigned to the story. If there is no consensus, further discussion is needed to uncover reasons for differences of opinion. The team votes as many times as needed to achieve consensus.

A team’s velocity is a measurement of the number of story points it can complete in a given interval, and it is the primary capacity measure used to determine whether the team can deliver a specific user story in a particular timeframe. Hence, assigning story points to user stories is a critical prerequisite to accurate planning within both the Program and Team segments.

Common Pitfalls

The following problems can occur when estimating work using a story point approach:

  • Trying to normalize story points across teams: Story points are an arbitrary measurement that reflects a particular team’s assessment of effort. What one team views as a 1-point story may be a 5-point story for another team, whether because of difference in skillsets or personnel or a different baseline for pointing. For this reason, it’s a mistake to compare one team’s velocity to another, or to infer any kind of absolute level of effort from story points across teams.
  • Relying on a lead instead of the team for estimates: Story point estimation and activities like Planning Poker can be time-consuming for teams. For this reason, organizations often attempt to streamline the process by relying on certain individuals like a development lead to provide estimates on behalf of the team. This approach is a mistake; not only does it exclude certain viewpoints that may be needed for a more accurate estimate, but it increases the likelihood that teams will be unwilling to make commitments during planning because they do not want to be held to estimates they did not agree to.
  • Not taking into account non-development work: Story points should not be just an estimate of the amount of development work required to deliver a story. If tasks such as design or quality assurance testing are part of the story’s scope, they should be included in the story point estimate. For this reason, story point estimation is an activity that should be done by all members of a cross-functional team, not just the development staff.

Tools

Agile project management tools such as Atlassian Jira or Agile Craft support story point and velocity tracking, while a variety of resources such as PlanningPoker.com exist to help teams with the estimation process itself.

References