2.5 Agile Estimation

Agile estimation is the process for estimating the effort required to complete a prioritized task in the product backlog. This effort is usually measured with respect to the time it will take to complete that task, which, in turn, leads to accurate sprint planning. Agile estimations are essential for:

• Making teams accountable for deliverables
• Inducing discipline across the Agile team
• Predicting the approximate time it will take to finish a project
• Enabling better sprint management
• Improving team productivity

Consider the following in Agile estimation:

Collaborating with the product owner: Estimation process in an agile development begins with questions about requirements and user stories. These questions help the entire team understand the task fully. For product owners specifically, breaking down work items into smaller pieces and estimates via story points helps them prioritize all and potentially hidden areas of the work and once estimates have been provided from the development team, it is not uncommon for a product owner to reorder items on the backlog.

Agile estimation is a team effort: Estimating resources and in particular cost using agile development approach involves everyone on the team. Each team member brings a unique perspective on the product and the work required to deliver a user story.

It is important to include all team members in the estimation process. Leaving team members out may create lower quality estimates, lower morale and compromises the quality of the product.

Story points vs. hours: Traditional project teams give estimates in a time format: days, weeks, months. Many agile teams, however, have transitioned to story points. Story points are units of measure for expressing an estimate of the overall effort required to fully implement a product backlog item or any other piece of work. Teams assign story points relative to work complexity, the amount of work, and risk or uncertainty. Values are assigned to break down work more effectively into smaller pieces, so they can address uncertainty. Over time, this helps teams understand how much they can achieve in a period and builds consensus and commitment to the solution.  It may sound counter-intuitive, but this abstraction is helpful because it pushes the team to make tougher decisions around the difficulty of work. Here are few reasons for using story points:

• Dates do not account for the non-project related work that inevitably creeps into our days: emails, meetings, and interviews that a team member may be involved in.
• Dates have an emotional attachment to them. Relative estimation removes the emotional attachment.
• Each team will estimate work on a slightly different scale, which means their velocity (measured in points) will naturally be different. This, in turn, makes it impossible to play politics using velocity as a weapon.
• Once you agree on the relative effort of each story point value, you can assign points quickly without much debate.
• Story points reward team members for solving problems based on difficulty, not time spent. This keeps team members focused on shipping value, not spending time.

Story points go wrong when they are used to judge people, assign detailed timelines and resources, and when they are mistaken for a measure of productivity. Instead, teams should use story points to understand the size of the work and the prioritization of the work.

Story points and planning poker: Teams starting out with story points use planning poker. The team will take an item from the backlog, discuss it briefly, and each member will mentally formulate an estimate. Then everyone holds up a card with the number that reflects their estimate. If everyone agrees, great! If not, take some time (but not too much time–just couple minutes) to understand the rationale behind different estimates. Remember though, estimation should be a high level activity. If the team is too far into the weeds, take a breath, and up-level the discussion.

Estimate smarter, not harder: Spending so much time estimating work that is likely to shift is a waste of time. Providing the product owner with an estimate that can be used to prioritize the product roadmap appropriately is the best approach. By the time the team begins to work on items, the requirements may have changed, and any estimates will be inaccurate.

Learning from past estimates: Retrospectives are a time for the team to incorporate insights from past iterations–including the accuracy of their estimates. Many agile tools track story points, which makes reflecting on and re-calibrating estimates a lot easier.