Why you should stop using Story Points and use Smallest Releasable Units instead

There are no two identical projects. It’s a cliché expression, but even the most skilled PM ninjas sometimes forget about it. Type of product/service, the situation on the market, technology, people, budget, timeline — even small changes in one of the variables may (and should!) affect the way we plan our software projects.

Although IT project management is a relatively new field, it develops so fast that there are already a lot of approaches and methodologies on how to organize the work: Agile, Scrum, Kanban, Lean, Waterfall, Six Sigma, PMI/PMBOK… You’re probably familiar with at least one of them. These are all great tools that are proven to work well.

Yet, a lot of IT projects (if not most of them…) still fail to deliver. Each failure is caused by a series of wrong decisions and it often happens at the very beginning — during project estimation.

That’s why our bunch (yes, that’s why we’re named Bunch Consulting) made of PM veterans gathered some thoughts on the popular Story Points. We also share an alternative approach, so make sure you read our article to the last paragraph — it’s worth it ;)

Why Story Points can be dangerous

Estimating with Story Points helps us estimate and compare the amount of work to do, risks and uncertainties, as well as complexity within a project. Point system lets us easily overlook the tasks — an activity “worth” 4 points requires twice as much effort as an activity with 1 point assigned. However, it can also cause many problems.

First of all, the points only represent the relative values between tasks. The basic value is then subjective and, as a result, hard to understand for people from outside the project, i.e. our boss, investor, client, etc.

Secondly, points don’t answer the most basic questions our stakeholders ask: “When?” and “How much?”. Reporting that your team has “18 points left to do” can mean “we’re doing great” as well as “we’re screwed”. It’s essential for a project manager to “translate” these values. Since the points don’t represent time or money, they’re not comparable between different projects.

Lost in translation

Conflict of interests can kill the team or make it invincible. The owner wants to have it done as fast as possible and as cheap as possible. The developers want to know how much time they have to finish the tasks up to their tech lead’s requirements, who wants to have as much time as possible for the tests. The sales team wants to start selling and making commissions asap and the marketing team needs to know the exact date of release to set up the campaign properly. The list goes on and on.

There is one value that all the above parties share: time. The answer to “When?” or “How much time?” is the lingua franca of project management. At the same time, basic tools such as clock and calendar are not enough to map out a set of complex tasks that lead to developing good software. What can be used instead? Read on!

Smallest Releasable Units — the common language

If you’ve heard of Most Valuable Product or Minimum Releasable Feature, this one will sound familiar. Smallest Releasable Unit is a basic value that makes up a task within a project. It means breaking down the tasks into the simplest activities that can be finished independently.

To use the tool, all the members of the team need to cooperate. Defining the smallest tasks should be done together, during a couple of meetings.

After announcing the key product features and deadlines during the first meeting, each member comes up with a comprehensible to-do list that leads to achieving the bigger goal. The meeting can be conducted in the form of a brainstorming session after which all members can work on their own Smallest Releasable Units. The next meeting is then about making the shortest path to achieve the MVP.

Easy is hard. Or is it?

The beauty of this approach lies in its simplicity. Defining smaller tasks and understanding them within a team gives members a psychological edge. They feel that they can start the process immediately and complete the tasks one by one, not being overwhelmed with the big picture.

For instance, instead of estimating (which is often just guessing) that creating an interface for a web app will take 10 hours or 6 points, the dev team writes down that they need to design a search engine and a sorting feature that will take x and y hours respectively.

On that stage, they should know to what extent these features are necessary to deliver the MVP. Is search autocomplete a must or can it be added later? What about as-you-type autosuggestions? The scope of the Smallest Releasable Units needs to be clear before starting the actual work.

The devil’s in the detail

The above saying sums up the topic nicely, but we’re tempted to add a small twist to it: the devil’s in the right detail. Estimating projects “by the book” at all costs can be harmful to the whole process. A common understanding of what features the MVP has and defining the basic tasks to build it are absolutely essential.

If you’re a bit overwhelmed by all the above… We understand. And we’re here to help! At Bunch Consulting, we strive to help our clients understand how the IT market works. We build a professional team that delivers the project within the timeline and budget. Reach out to us at [email protected] if you have a project in mind and we’ll gladly prepare a rough estimate for you.