Story point – a revolution in task estimation? part 2

When not to use user story points?

When we see many benefits of the change in the approach to estimation, it can be assumed that the story points are better than the time estimates. In my opinion, this is not true, just as Scrum is not always the best way to implement the project – as I will explain in more detail in the next article. Why? Because both methods are not the same tools. Just as a screwdriver is not an improved version of a hammer, the story points are not a better version of working days. And although you can hammer a nail with a screwdriver and screw a nail with a hammer, this style of work will not bring spectacular effects.

When will a story point not work as well as man day?

High staff turnover in the team

If the staff turnover is very high, the speed and accuracy of estimation in story points will always be in the calibration phase. A popular view is that it takes about 3-4 sprints to achieve reliable data on the speed of the team. Therefore, if we have a change in the team every month, achieving the expected accuracy is much more difficut.

Small team

When we deal with a one- or two-person team, there is no point in estimating work based on abstract values. We can collect very accurate time data. Additionally, with small teams, the benefits of using Scrum do not reveal themselves sufficiently. The amount of communication in a two-person team is too small to use a framework for this task.

Short, repeatable project

When a project is short and concerns a repetitive, simple task, for example, installing a patch on subsequent environments in different countries. Of course, each implementation may be different and unforeseen situations may happen. However, if in 99% of cases we can determine the implementation time, the estimation in the story points loses its advantages.

No knowledge of agile management methods

Estimating in story points in a team requires some sense and maturity in agile management methods. If the adventure with this estimation begins with a large valuation of the entire project, it may turn out that this task is too ambitious. Small “frauds” (converting story points into days) or very inaccurate estimations are likely to happen.

Various competences

If a team consists of several people with completely different skills, e.g. a scientist, developer, and machine engineer, finding a common reference point can be much more difficult. It is not impossible but at the beginning, it requires more time than in a team having skills from related fields. Additionally, it may turn out that each of the specialists works on their own, in isolation – then defining a common story point becomes even more difficult.

The above examples are debatable, but my goal is to show that there is no ideal method for estimating work – story points are also not perfect. When implementing a project, it is always necessary to consider which tools will perform better under certain conditions.

The Agile Imperative

Currently the real problem in the world of the project management is an orthodox approach focused on a thoughtless implementation of the Scrum Guide or the other source. What’s even worse, every other tool of the traditional project management seems to be a bad one, obsolete and inappropriate. In my opinion, a 17-page manual, which in the Scrum Guide’s case is the introduction to Scrum, even if written in a very generic way, does not relate to the particular cases. It’s the same situation as with other books, courses and podcasts etc. I even met with the opinion that Scrum is a kind of a bible. Knowing it’s an intentional exaggeration, I believe it’s a harmful approach that characterizes people less confident in their knowledge from areas outside the narrowly understood Scrum.

The role of a Scrum Master or a Project Manager is to skillfully adjust the tools to the project rather than to use one method as a panacea, regardless of the case. It’s worth mentioning that just in case of Story Point, it isn’t something that results from the Scrum Guide, it’s a concept created later.

The value of the Project Manager is visible only if he’s able to adjust the tools to the right goal, not being guided by personal likes or the desire to demonstrate the deep knowledge in a specific area.

In conclusion, techniques used for estimation, just like any other element of the project management methodology, should be adjusted to the conditions, to the type or organization maturity model. It’s not an art to force an implementation at the cost of quality, project’s clarity and the team’s morale. When planning the approach for the project, it’s worth keeping in mind the above list of circumstances, which in themselves do not prejudge anything, but should encourage to a deeper thoughts on the chosen path.

In the next article in the series, I will discuss an issue of Critical Path in terms of estimation in Story Points. It’s a matter connecting agile world with frequently occurring business expectations. I invite you to read it next week.