Estimating software development projects is no easy feat. A traditional waterfall approach involves a lengthy requirements-gathering effort, resulting in complex documentation and a project plan with estimated hours and dollars. Today, Agile development methodologies have largely become the new normal, with the key benefit of providing the ability to quickly assess how long it will take to complete a project and how much it might cost.

At Randstad Digital, we advocate for quickly building a high-level feature list and using Relative Story Point Estimation to more accurately estimate costs and level of effort

what is relative story point estimation?

Relative Story Point Estimation uses a “unitless number” to estimate user stories by grouping requirements based on equivalent difficulty. In simple terms, it is a way of sizing user stories relative to each other. A story point is an arbitrary measure of effort required to implement a user story; it’s a number that tells the team how hard the story is. “Hard” can be related to complexity, unknowns, and/or effort. In most cases, a story point uses one of the following scales:

1,2,4,8,16
X-Small, Small, Medium, Large, Extra-Large ( known as “T-Shirt Sizing”)
Fibonacci sequence: 1,2,3,5,8,13,21

Since story points do not correlate to actual hours, it makes it easy for Scrum teams to think in more abstract terms about the effort required to complete a story.

Here's how it works:

Step 1: Create a product backlog.

The product backlog is where requirements are stored on an Agile project in the form of user stories. The user stories should be epics and contain high-level features of the system.

Step 2: Determine the scale.

We typically use the Fibonacci sequence numbers like 1, 2, 3, 5, 8, 13, and 21 to convey a level of effort.

Step 3: Estimate the backlog.

Outline the items that don’t need detailed thought upfront; this will create a rough estimate of the scope of the backlog.

Step 4: Create Release Planning Estimates.

Determine the team’s velocity (assuming you have access to historical data) and approximate release dates.

Step 5: Get Specific by assigning points as a team to stories for development, testing, and elaboration.

Planning Poker is a simple and collaborative way to size your backlog as a team.

Step 6: Create Sprint Planning Estimates.

These are the items that we’ve discussed and broken down in detail as a group; part of sprint planning. Here is where tasks can be planned in terms of hours and sprints, since at this point we know more detail.

Relative Story Point Estimation provides the following benefits:

It's quick.

The goal of story point estimation is not to come up with an exact level of effort because there’s too much uncertainty and not enough time. Rather, the goal is to quickly estimate a level of effort, and you can do it much faster than you can when using traditional estimating approaches.

It’s more accurate.

Planning each sprint in terms of hours or dollars needed to complete may be a precise method, but if you run even slightly behind schedule, the scope of your whole project can get thrown off. We call this the cone of uncertainty. By grooming the backlog, you resize and develop quick estimates of effort in an Agile manner. When the work starts, you can give a more detailed estimate, thus shrinking the cone of uncertainty. The rough classifications of story point relative estimation are a more accurate and flexible way to determine priorities and schedule.

It gets better with time.

Over time, you can look at how many points your team typically completes within a sprint, and become better and better at relative estimating. This picture of velocity helps gauge development team effort over time, determine what your sprint capacity usually is, and serves as a good tool for predicting future estimates.

It’s project-specific.

It’s nearly impossible to predict an exact amount of hours for any given story because hours are relative numbers. Generalizing to a few significant numbers allows you to attain a more accurate “big picture” of velocity that is tied to the specific project at hand.

Software development is burdened with high levels of complexity and unknowns. While there is no perfect way to estimate how long a particular feature will take to be completed, our Agile teams at Randstad Digital have found that relative estimation offers many benefits through a simple and elegant Agile development process.

Ready to optimize your Agile development process with Relative Story Point Estimation? Learn more about how Randstad Digital can help you streamline your projects.

categories

topic