Why should you consider working with story points?

The article starts with the basics, helps to kick-start an estimation and discusses how it is different from the traditional project estimation approach. The proposed method using Story Points is typically used by project managers who work with their teams in an agile framework.

I personally use the story points to size the backlog, estimate the project’s budget, provide an initial timeline, report progress, size changes to the project, and enable Product Owners to make better business decisions based on ROI (Return on Investment).

What’s a Story Point?

A Story Point (SP) is a relative measure of an item in an IT product backlog. Backlog, a prioritized list of features from a user perspective, contains Product Backlog Items (PBIs).

Each PBI is typically a user story, hence story points.

The number of Story Points assigned to a PBI covers effort, complexity, and risk - all three.

Historically, it was only a measure of complexity. Over the years I started adding the other two dimensions, which has helped me in successful delivery of projects.

Estimation & scheduling the project management way

Typically, when starting an IT project, you need to answer some of the basic questions: what? (scope), when? (time) and how much? (cost). The main ingredient of cost in IT software development projects is usually the effort spent on creating features (programming). The estimation is done in man-hours or man-days. When the estimation is ready, the ‘when’ question is answered using a scheduling method. For instance, it’s done by dividing the effort by team members per group of tasks that are to be implemented including dependencies, team availability and numerous other factors.

In the end, the project manager provides the baseline for the budget and timeline. The dates and number of man-hours are recorded, and the project success is gauged against it.

Unfortunately, developers and project managers are not fortune-tellers, and they can’t see the future. For starters, they can be wrong: under- or overestimate just because of project’s nature. Several risks may or may not materialize. The project conditions might not be ideal for a fast pace delivery (delays in decision process, random obstacles, previously unknown coding standards required, etc.). The assumptions taken into account during the original estimation may turn out to be invalid (libraries/tools don’t simplify work as much as was assumed). The project environment might change, and the deliverables have to be aligned with it.

When any of the above issues occur, it’s often hard to estimate the impact on the estimate, as that process is prone to the same flaws as the original. Changing the man-hours estimates against affected tasks may not be practical as it distracts the team from what’s important, which is always project success and programming.

The estimates against each task are only estimates and they’ll not change when the project is completed (in some cases the cost projections may cause the project to be closed abruptly). Discussing the impact with sponsors and product managers is not an easy task.

A better way to estimate your software project

Having a rough idea about the overall cost of the project is more important than individual estimates for each task. It’s generally better to focus on delivering value, and only validate the initial estimate and resulting project plan along the way.

Using Story Points for estimation goes like this.

1. You (as a Project Manager) invite a team of experts: a business analyst, a software architect, a product designer, and specialists like front-end or back-end engineers.

2. You begin the exercise by sizing the PBIs relatively to each other.

3. You select one item that is well understood by every team member; ideally something simple and without significant risks.

4. Then you assign that item (PBI) a measure of 2 SP. An industry-wide approach to use a Fibonacci sequence for the scale. The simplest items have 1SP, then 2, 3, 5, 8, 13, 20, 40, and so on.

5. The next step would be to estimate all the remaining PBIs in relation to the initial PBI which was assigned 2 Story Points.

If it’s really hard to size an item in relation to the ones already estimated, then you skip it for now, pick another, and get back to the difficult item later.

If the item is trivial, you give it 1 SP.

If there’s roughly 50% more effort necessary to implement the next PBI compared to the first one you tried, you assign 3 SP. The same would be done for 5 SP, 8 SP and so on…

If there’s a risk around an item (e.g. if something is unknown which could result in extra work), you try to guesstimate the possible impact. Typically you’d raise the story point value by one step, for example from 5 SP to 8 SP.

If an item is complicated, e.g. a complex algorithm, you follow the same approach, assigning a higher estimate. How much higher? Probably, the next step from the sequence, or whatever the team feels is appropriate.

After you do this for every PBI in the backlog, you have completed the initial phase of the estimation.

After sizing the whole backlog in Story Points, you’d estimate ~10-25% of backlog in man-hours. Then you’d extrapolate the total budget and the expected velocity of the team (simplifying: average SP per sprint). For instance, assuming: 10% of the backlog is estimated, the estimation in hours is 320 man-hours (including bug fixing, code review, tests, etc.), the total backlog is 300 sp, the team spends 15% on scrum meetings, the available hrs capacity is about 320h / team of five in a 2 week sprint (excluding average sick leaves, public/private holidays, other activities), then the initial expected velocity would be 20 sp/sprint. Then the optimistic scenario you’d consider should contain at least 15 two weeks sprints, which gives the optimistic budget at the cost of 5 people throughout 15 weeks plus some project management and other non-manpower costs.

Then the typical scheduling and planning are to be performed - this is done to include dependencies, assumptions and other factors.

Working with a backlog and reacting to changes

Once the project is underway, after a few sprints (minimum 2), you begin to verify the initial expected velocity against the real one. You keep doing this regularly.

If there’s a difference, the causes/reasons should be examined and the timeline, budget and other changes can be managed. The plan is aligned according to the new (measured) velocity of the team.

After some time, the velocity will usually stabilize and the potential risks will already be included in the plan.

Should you have some environment changes, then it can be estimated roughly against the whole backlog and the velocity can be aligned.

Should you have a new kick-ass feature that will bring a lot of value to the product, then you’d ask the team to size the idea in SP, and you would be able to judge how ‘big’ this is in terms of effort and if it’s worth implementing.

When you use Story Points, everybody understands that an estimate is only a number which approximates the required effort in relation to other items. It’s not absolute.

Meanwhile, the estimations presented in hours or days are too often taken as written in stone, something that might be planned for and executed with a high level of accuracy compared to baseline. This rarely leads to a productive relationship between the team building the product and project sponsors.

Key takeaways

Benefits of using SP

• realistic planning based on velocity with an approximate impact of un-materialized risks
• team working with one backlog supporting each other to make progress. When you stop using man-hours as a unit of estimation, people are more engaged in working together and accomplishing the goals rather than checking whether they work as long as was expected of them (with less regard for common goals)
• a useful measure of a project progress

What stays the same with SP as with time-based estimates

• Communication between all parties is still key to deliver what’s needed, including managing stakeholders and their expectations
• The fact that you use SP doesn’t mean you must add a professional Scrum Master to your team. You can keep the same team structure as you had before, and the effort necessary to introduce the concepts can be covered by whoever is already on the team.
• You still need to manage risks, issues, assumptions, changes, and dependencies
• You still have to figure out your commercial model: fixed-price or time & material

Tips and tricks

• Make sure the SP are roughly additive: the team should, on average, be able to finish one ‘8-story-points’ PBI using approximately the same amount of man-hours, as two items worth 5 SP and 3 SP. If this is not the case over a longer period of time, it is likely an issue with the way team has been assigning the values.
• Estimate the backlog with the same team that will actually work on the project
• 1 SP should be around 1-3 days of total effort. Usually, it’s closer to 1 day or an 8-hour workday. This will cause the backlog granularity to be at a manageable level. It also stems from the way how 1 SP effort of a user story is defined - it is supposed to be trivial that brings value to the user, and a day is often enough to provide it in the world of software.
• The team should be able to complete the largest item within a single sprint, to follow the general practice of delivering working software at the end of each sprint. If it’s not the case, ask the team and Product Owner to split up the item such that each part can be completed within a sprint.
• If an item is estimated to be worth more than 40 SP (some teams use e.g. the value of 100 SP for it), then break down the PBI into smaller ones, even at the beginning of the project. Too many high SP estimates may result in the less predictable project, due to a large potential impact of unexplored risk/requirements.
• Make sure the team understands the estimate and the way velocity is projected - they will be more likely to work with the project manager or product manager to be close to the overall plan (mainly schedule)
• Check if the initial calculated velocity (e.g. ~30SP/sprint) is in line with the team’s gut feeling - if they feel like delivering the scope of the first three sprints (i.e. ~90SP) using velocity calculations in the available time. Using the values (velocity: ~30SP/sprint; 3 sprints) and assuming 2 weeks sprints, check if the team feels that they can deliver ~90SP in 6 weeks’ time.
• After the backlog is sized, look at buckets of items which have the same size, and ask the team to verify that the effort, risk and complexity for each are actually comparable. This is an easy way to spot potential misunderstandings or mistakes early on.

Contact our business analyst now!

When not to use Story Points

• The team is not stable throughout the sprints
• The team is rather small (1-2 developers)
• No need to provide a schedule (e.g. pure R&D flow)
• The project is shorter than 2 months
• Nobody is familiar with Story Points or, more generally, agile frameworks, and everybody feels comfortable with estimation in man-hours and a proper project management structure is in place
• The team members work in isolation - i.e. iOS, Android and web development are not in sync and largely independent.