How to Calculate Story Points

Story points are an arbitrary measure of how difficult each phase of a story will be to implement. They are used by scrum teams to represent the effort and complexity of a project, rather than the hours that actually go into completing tasks and objectives—a model that's useful when team size, productivity, and other external factors can't be predicted.

Because every team works at a different rate, you might not be able to predict the exact time frame of any given story—but representing the effort as story points can provide a constructive framework for future planning and implementation. All of this depends, though, on accurately predicting story points.

As a rule, the most effective story point calculation comes from the collaboration of your entire team. As you discuss story points, start with a list of tasks that can be divided into stories. Select the simplest of these tasks and set the story points for this task at 2. The points value of other tasks will be calculated relative to this value.

From there, you'll tackle the other stories individually, allowing each team member to vote on a story points value, then discussing the votes in order to understand why certain tasks are more or less complex than others. For a truly effective story points model, you’ll need to take each team member's input under consideration and reach a consensus on each task before moving on to the next. Through this process, you'll create a system that makes it easier to estimate the time frame for a variety of tasks and to assign fair, motivating targets for your team.

Agile vs. Waterfall

It's a topic that’s endlessly debated at project management meetings and trainings, yet there is still no general consensus over whether Agile or Waterfall is the more robust model—and there probably never will be! Each PM methodology has its own strengths and weaknesses that make it appropriate for certain teams and situations. The following is a very brief summary of the differences, benefits, and drawbacks of each.

Understanding the Basics

As the older and more traditional model for software development, Waterfall depends on the early development of a logical plan that works in a very linear manner. In fact, each stage of a Waterfall project may have a different team and its own unique objectives, moving forward toward completion in an organized model with a planned timeline and goals.

In contrast, Agile was developed to circumvent Waterfall's biggest problem: the inability to make changes to a project's plan without essentially going back to the drawing board and starting over. Agile is open to later input and adapts easily to changes. It's also known for presenting a much lower starting overhead and more leniency in absorbing mistakes.

Predictability vs. Flexibility

While Waterfall makes it possible to predict, plan, and schedule project steps in advance, Agile offers flexibility and adaptability. Agile is superior at handling the inevitable bumps in the road that most projects experience, but it's not as effective at predicting in concrete terms the course a development project may take, the timeline, or even the eventual outcome.

Changes and Collaboration

In Waterfall, it's very difficult to go back and make changes to existing code without redesigning the entire system from scratch. That's because each stage is planned in advance to flow naturally from the one before it, sometimes with a new team assembled for each stage.

When using Agile, on the other hand, it's much easier to involve customers in your project as it develops—in fact, customer collaboration is one of the Agile watchwords—and to improve on previous work over the course of a software development project.

Agile or Waterfall: Which Methodology is Best?

The answer will depend mainly on the scope and goals of your project, as well as the technology you're using and your client's guidelines and approach to feedback.

There's no definitive argument that one approach is better than the other—but there are certainly better choices for individual projects and programs, depending on whether your customer has a concrete goal and timeline at the start or will want to provide input during the course of software development.