The estimation of a new project is always one of the key moments of the sales process, as it will very likely be the base of the agreement with the client.

The project manager is usually the owner of this activity, the ones responsible for challenging the estimates provided by the team and explaining the sales why the project will take twice as much time as what they initially told the client.

The primary responsibility of the project manager is to ensure that the team provides the estimates at the best of their knowledge of the project and that the product owner is available to reply to every question they might have on any requirement.

However, what is the best way to estimate a new project?

Somebody would say, how can we ensure that our estimates are as much accurate as possible? However, I tend to consider “accurate estimate” an oxymoron, unless we adopt a range of values, associated with a confidence level, as our estimates.

That said, there are several methods to evaluate a project and the choice amongst them should reflect the pre-existing process established within your organisation. The methodology adopted for delivering, for instance, will determine whether or not you can estimate with Story-points – which would not be possible in a Waterfall project.

Story Points

After decades of wrong estimates, somebody finally came out with the idea that maybe we are not that good at estimating time. Agile does not prescribe any estimation, but since Scrum, for example, mandate a commitment from the team, that is only possible if requirements are somehow estimated.

Using an abstraction, like “points”, that moves the focus from the actual time to describing the relative complexity of a task as compared to others, sounded a much better choice than time.

Although there is no direct relationship between points and time, the number of points delivered by the team in a single Sprint is called “velocity”. A team’s velocity, refined sprint by sprint, creates an indirect relationship between points and time: a backlog estimated at 95 story points can be delivered in 6 Sprints by a team with a velocity of 16 story points per Sprint.

More in details, during the estimation process the team must agree on the complexity of every story and ultimately on the number of story points assigned to it. However, they cannot just assign any number, because the larger the story is and the more uncertainty there is around it. The uncertainty is represented by deliberately creating a lack of precision: that explains why the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, 55) or powers of two usually offer the series of points that the team can assign.

Mike Cohn, one of the most prominent promoters of Agile, successfully formalised a gamified version of the estimation with story points, the so-called planning poker. The team sits together and discusses the user stories one by one, analysing its content, making the right questions to the product owner, and when ready they all raise a card showing the story points they want to assign to it in comparison to the baseline.

This approach, however useful, is not clear from pitfalls, most of which depends on misinterpretations of Scrum and how to estimate stories.

The one thing that you have to ensure as the project manager is that your team feels comfortable with the following statements:

There is no relationship at all between story-points and time.

and

How a story is estimated should not be affected by the seniority of the team member.

Although there is always consensus on these principles, the disrespect of the same is also one of the main reasons for the story-points to become worthless. It is a project manager’s duty, to drive the team towards the right behaviours.

Associating story points with effort is almost in the human nature since our job, and our performances have always been associated with time and how fast we can perform tasks. Somebody new to Scrum or story points may easily mistake the concept of story points and invalidate the estimate.

Unless your team is very well trained to proper story pointing, you might want to explain how story points should work at the beginning of your project.

Story Points and Time

Name two cities, the one where you are at the moment and another one relatively close to it, where people might usually go for work or pleasure. I often use London and Brighton.

Now ask your team how long it would take them to go from one city to the other with a bike. The answers would inevitably depend on the cycling skills of each of them, on the quality of their bike, somebody might even say that he or she would not be able to get there without some stops. That is the problem with estimating time.

Now ask them how far they think the two cities are from each other. The answers should be much closer to each other.

That is exactly how points should be assigned to a story, i.e. detaching them from any personal implication.

Points and expertise

Somebody could still argue that points are inevitably tied to the seniority of the individual estimating the story. In the previous example, it would depend on whether or not the person has ever gone to Brighton from London, if he or she has any perception of distances – many people without a driving license do not. Another example might help to refute this statement.

Imagine that instead of software, the team was requested to weave some clothes – something they probably lack expertise on – and that a mere handkerchief was the baseline.

Now, even in the complete ignorance of how to weave anything, the team might agree that if the handkerchief is one story point, a scarf could be two, a sweater not less than five, and gloves, however small, may be eight story-points as the fingers look rather complicated.

The reality and conclusions

Even if you are not the Scrum Master within the team, you will probably want to discuss these problems with whoever is covering for the role, especially if the team is not used to work together.

A few suggestions that might help a brand new or inexperienced team:

  • it is useful to have more than a single baseline, preferably from different projects;
  • bring the attention to the baseline and similar stories you already pointed, before estimating any new story;
  • establish what is the threshold to slice a story in smaller pieces (e.g. any story bigger than X points);
  • try and make your stories I.N.V.E.S.T.;

Please add your comment below, sharing your experience or your thoughts.

You may be also interested in:

Share This