Story Point Estimating Taking the Guessing out of it

A lot of teams still struggle with giving accurate time estimates using story points. It’s among the most difficult, if not the most difficult, aspects of the software team’s entire job functions. The same team can solve the most complex software problem, however, find it very difficult to estimate the simplest of tasks.

Determining whether your team has an estimation deficiency?

Does your team do any of the following:

1. The team uses hours instead of Point system
2. Estimates are typically wildly off what they had originally stated
3. The team is frustrated and don’t see the value in estimating work item

Fortunately, there are methods that we can use to develop reasonable estimates. One of the most effective methods, in my opinion, is a group discussion with a slightly diverse audience.

A story point is a unit of measure to express the overall effort that will be required to fully implement a work item. Varying teams use a different approach to measure:

• T-shirt size (S, M, L, XL)
• Fibonacci (1,2,3,5,8)

A story point is a unit of the collective team effort.

Setting the Team formation

It’s important to have the right people involved in the estimation process. By incorporating persons from other teams (Software developers, UX designers, QA, ….Everyone) each role brings a different perspective on the product and the work required to deliver a user story.

Take for example, creating a login page.

As a Customer, I want to be able to input my username and password to get access to the application, this will ensure my personal information is secure.

Most developers will say this is a pretty cut and dry User Story, however that is one perspective of the whole.. Here are the others:

Software Developer: focus on the functionality of the log in such as the user credential and how the information will be pulled from the database to verify the user.

UX Designer: focus point will take into consideration the look and feel of the login page, how to maximize the user experience, color layout, etc.

QA Tester: focus goes beyond functionality and how it works but to take into consideration scenarios and how the system reacts to having consecutive invalid password entry.

Architect: focus at a high level on how this basic functionality integrates with the larger system as a whole.

By including the various focal points in the estimation process a higher quality estimate is created.

Estimate made in a Vacuum, it is a fast track to Failure!

Where to Start — Collaborate with Product Owner

The Product Backlog is an ever-growing list of user stories that connect the business requirements and defects identified within the system. These are all managed by a single individual, the Product Owner.

The entire team needs to rally around the Product Owner, who provides the list of priorities and details regarding each user story. This phase of collaboration links the business requirements (Needs) to the technical implementation (How). It also starts the estimation process as the team asks questions for items that require further clarity. Answers, in turn, will provide the team with enough context to accurately estimate the User Story.

Additionally, the story points help the Product Owner prioritize which User Story can be grouped into which sprint cycle based on the team’s capacity and velocity. It is very common for a product owner to reorder items on the backlog based on the collaboration with the entire team. Typical for the Scrum to tackle these activities during the Sprint Grooming ceremonies.

Running Estimation sessions — Playing a Game of Point Poker

Now that you have formed your team, how do we avoid groupthink and disagreements for the final estimate? The true strength of a diverse group is its diversity. Therefore, use that which makes us different as the core purpose in every estimation session by allowing every individual to base their estimates base on their domain expertise.

Let’s move into the game of Pointing poker.

At its simplest, Planning poker is a gamification approach of estimation sessions wherein a team of estimators follow an iterative process of blind estimating with cards on a Fibonacci scale until the team agrees on one final estimate for each development task.

The team will take an item from the backlog, beginning with the highest priority and going down the list. The Product owner will give a brief description, and each member of the team will estimate its effort. The members will formulate a whole estimate, and everyone will reveal their estimate at the same time to prevent groupthink. There are many tools out there to engage in planning poker, for example, T-shirt size or Fibonacci numbers

There are three (3) possible outcomes:

1. If everyone selects the same value then, it’s given to the User Story.
2. If two or more persons have a wide variance of the estimate, then the members discuss how they arrived at those estimates and the team makes the final decision.
3. If the User Story has too many uncertain elements for the team to commit an estimate to, then the Product owner can intervene for further clarity or request clarification from the business.

Bench-marking Stories

It has been proven that Humans are much better at estimating using relative rather than absolute estimates. If our teams compare one User Story to another it’s much easier to estimate the Story point. Relative estimation is the use of current and/or past features as a benchmark for the sizing of new ones.

For example, if Feature A was estimated at a story point of 3 and Feature B is a less complex feature in comparison to Feature A then the team can assign a Story point of 1.

Teams must keep this in mind when providing relative estimates on a specific story. It is a combination of the amount of work required, the complexity of the functionality or even familiarity with building the said feature, and finally the level of risk or uncertainty. In using relative estimation with an already estimated User Story, teams can decide to go higher or lower. Teams tend to iterate on this process and will only get more accurate over time as they work together.

Using the Relative estimating technique will allow teams to have more confidence, decrease the estimated variance, and decrease the effort exerted to give accurate estimates.

From Story Points to Hours

Now, although Agile teams work in Story point, the business we serve requires some level of the timeline for implementation. Therefore it is left to the Project Manager to translate the Story Points into hours. Here is a really effective way of doing so, first we have to introduce a few new terms:

• Capacity — The amount of work a team can do in a specific Sprint
• Velocity — Measure of the amount of work a Team can tackle during a single Sprint and is the key metric in Scrum

Using these metrics can help the Project Manager create a better timeline to share with the key business stakeholders. Based on the team, velocity determines how many User Story, based on the estimated size, can be completed within a given sprint, taking into consideration the team capacity during those sprints. This can be used to forecast how long it will take to complete a backlog of activities.

The forecast completion gets more accurate over time. The team performance data over a longer period will help the Project Manager better assess the team’s projected end date. Notwithstanding that the core of Agile is doing an incremental release, therefore, the most important features would be live before the entire project wraps up.

Factors Affecting estimation:

1. Not having the right composition of team member involvement
2. The availability of information to do accurate estimations (partially missing or incomplete)
3. Lack of refining team approach and estimates; learning from past experiences.