The formal definition of estimate is “an approximate judgment or calculation of the value, amount, time or size of something”. In a software development project, estimates are important to help us predict how much time will be necessary in order to finish a set of activities, or to select and prioritize scope for a release or iteration.

It’s rather common on Agile projects that the estimates are done in a planning poker session. Each team member has a deck of cards with the Fibonacci sequence (0, 1, 2, 3, 5, 8, 13), and for each user story (US), the team member privately selects one card to represent his or her estimate. All cards are then revealed at the same time. The estimates can represent story points, ideal days, or other units of cost that make sense to the project. Usually we use story points because we can consider three different aspects when estimating: complexity, effort, and risks. The story point unit allows us to more effectively capture sources of variation compared to an hour-based estimate.

Since story points are a relative measurement unit, the first step your team should take is to define one story as the baseline, so that they can estimate the other stories comparing to that reference. According to the literature, the team should find the simplest story in the backlog, and assign 1 story point to it, after that, they use that story as baseline to estimate the other stories.

However, here at Plataformatec we go a step further on defining that baseline story. We select at least one user story for each story point that we use, composing a “ruler score”.

Ruler score example

In each sprint, we update the stories in the ruler with US’s of the previous sprint, so that when our team meets for the planning poker session, they have at least one baseline story on each story point to compare to.

Using that practice has brought us a lot of benefits, such as:

• The estimation process is more effective because the reference to each story point is clear, reducing the length of the discussion among the team;
• Even if the team has a new member, the story point variation is reduced because this practice enforces a reference to each story point in the “ruler score”;
• The team members have the same reference for each story point, preventing someone from having an implicit story point reference that is not shared among the others;
• On each sprint, the estimates becomes more and more stable, since using the ruler score guarantees that the story point references are always updated.

That’s it! We’d like to know what are your practices in estimating using story points. And if you try out the ruler score, let us know your results!

• Nice! We used to establish a baseline using a CRUD for 3 points, and everything else based on that value. This ruler baseline is a great improvement, thanks!

• Rafael Barbolo

I liked the Ruler Score tool and liked the examples you added even more.

I am not fond of estimating stories using “points”. Points are subjective and it’s hard to translate them into effort, specially when you don’t have much work history on the project. That’s why I prefer using days rather than points. In this way, it’s clearer how much should be achieved in sprints (from the first to the last sprint) and how long an activity should take to be done.

Have you ever tried to use days instead of points? What do you think about that?

• Peter Saddington

Try this and change your numbers of complexity to 1,2,4,8,16 – It may not seem like a big deal… but in our experience the fibonacci can cause issues because the bottom set (1,2,3,5) are so close together. In terms of potential philosophical arguments… it helps to remove the proximity of the issue all together.

• Caroline Mota

Rafael,
Before joining Plataformatec I used ideal days instead of story points, but now I prefer to use story points because it considers three different aspects: complexity, effort and risks. In our experience, that approach has been more assertive in the predictability. However, we believe that the estimate technique used in a project should be the one that best suits to your scenario.

Thanks for the words!

• Caroline Mota

Nice tip! Thanks for sharing your experience with us.

• Nice post! We used Ruler score with relationship to day. We usually set a velocity constraint for how many points we can burn in one day. We can calculate this based in how many people are working on the project using WIP (Work in progress) limits.

• Caroline Mota

Nice! Thank you for sharing your experience with us! 😉