Agile Story Points

In traditional software delivery methods, the estimates are measured in terms of man days or calendar days. The Agile teams use Story Points as a unit of estimation to complete a piece of work.

Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work. When we estimate with story points, a point value is assigned to each item. The numbers assigned are in itself unimportant, what matters is the relative values. A story that is assigned a 2 should be of twice as much value as a story that is assigned a 1. In simple terms, a story point is a number that tells the team about the difficulty level of the story. Difficulty could be related to complexities, risks, and efforts involved.

Story points rate the relative effort of work in a Fibonacci-like format: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100. Agile uses the Fibonacci sequence to achieve better results by reducing complexity, effort, and doubt when determining the development time required for a task, which can range from a few minutes to several weeks. Fibonacci provides appropriate buckets for all sizes of stories thus improving the accuracy of estimates.

Where to start Agile Estimation?

To begin with, team would have to identify a baseline story on which everyone within the team agrees upon. It does not necessarily has to be the smallest one. Once it is decided, all you have to do is pick another story and ask: “will this take longer or shorter than the baseline story?”. Similarly, the sizing of all the other user stories can be derived by comparing them against the baseline.

You may define a limit for a story, say, 20 points is the upper limit. It’s simply too hard to estimate individual work items larger than that with a high degree of confidence. Ideally, no individual task should be more than 16 hours of work. When something is estimated above the 16-hour (or 20-point) threshold, that's a signal to break it down into more granular piece of work and re-estimate. A value of 8 points is considered as most rationale estimate for a story point.

The items down below in the backlog do not require such details as by the time work starts on it, the requirements may change, and the application would have certainly changed. Only a high level estimate can be given to the product owner to prioritize the product roadmap.

Story Points and Planning Poker

Agile teams around the world use Planning Poker to estimate their product backlogs. The team will take an item from the backlog, discuss it briefly, and each member will mentally formulate an estimate and select a card for that estimate. Then everyone holds up their cards with the number that reflects their estimate. If everyone is in agreement, the estimate is finalised; if not, team gets back into discussion to understand the rationale behind different estimates. After further discussion, each member re-selects an estimate card, and all cards are again revealed at the same time.

The poker planning process is repeated until consensus is achieved or the team members decide to defer that particular item until additional information can be acquired.

Benefits of Story Points

• Story Points are considered as a very stable index of estimation as it is independent of the skill or experience of the team members.

• It helps track a team’s velocity. Velocity is a measure of how much product backlog effort a software development team can successfully handle in one sprint. During retrospectives after each sprint, team members can discuss ways to achieve greater velocity with remaining stories.

• Story Points brings flexibility to re-plan product release deadlines without re-estimating all tasks, if members of the team are changed.

• It takes into account the non-project related work like emails, meetings, presentations, etc. which are inevitable part of daily work.

• Story points reward team members for solving problems based on difficulty, not for the time spent. Team members can focus on delivering value, not spending time.

Story points can be a hard concept to grasp. but like everything else in agile, estimation is a practice. You'll get better and better with time.