DEV Community

Cover image for How to start with Story point
Walter Nascimento
Walter Nascimento

Posted on

How to start with Story point

Newly formed or inexperienced teams often have doubts about how to do calculations.

Of course, the plan is to stay close to the estimates, but that doesn't mean the process should be stuck.

Estimates

Estimates help, right? But there is a problem with them that needs to be highlighted: the people. We humans have a hard time making absolute estimates.

It is impossible to accurately predict the effort. This is because there are several variables that can impact the process. On the other hand, we're great at creating relative estimates, and that's what needs to be taken into account when making them. The most viable estimates are those based on references.

Story points

Story points are the most used estimation unit by agile teams today to measure effort. This is because they use relativity and encompass important aspects such as task complexity and risks.

Effort

Often, the team may have an abstract idea of effort. In some cases, the team even confuses the concept with a deadline. Therefore, the first step in making estimates is to clarify this idea.

Explain to everyone that effort is related to three factors:

  • Complexity: The term is generally used to characterize something with many parts, where those parts interact with each other in various ways. So, when estimating, take into account the complexity of your system and make sure you have the necessary skills for the activity.
  • Skill: You become more skilled with training. So, think of skill as the number of times you've done it, or the amount of experience you've had in doing a certain activity.
  • Risks: How well-known is that activity? Do we have dependencies that need to be mapped? Do we run the risk of being surprised by some scope that we can't map right now or is it just too boring to do and can distract you? These are some examples that can be used to map risks.

Fibonacci

Normally, the Fibonacci sequence (0, 1, 2, 3, 5, 8, 13, 21, 34, 55) is used to measure story points. This happens because, if the interval difference is small, it is difficult to estimate. On the other hand, if the difference is greater (8 or 13, for example) the answer will be much clearer.
Fibonacci Sequence
1, 1, 2, 3, 5, 8, 13, 21

Example

First we take the fibonacci sequence and adjust it to our environment, in this example we will use 1,3,5,8,13,21, where:

  • Easy: 1, 3, 5 - Simple tasks that do not require much effort and complexity;
  • Intermediate: 8, 13 - Tasks of greater complexity or that involve third parties;
  • Difficult: 21 - Tasks that need to be divided into new ones;

Forms of use

  • Limit the scale to 13 points: if a user story is scored 21, it is certainly large and should be broken.
  • Score the least complex user story with 3 points: this is great practice. If the team discovers a user story that is simpler than the reference, just put it with 1 point.
  • Don't think about hours: using a points-hours conversion, for example 1 point equals 1 hour is not prohibited, but it may work very well for one context and not so well for another. The tip here is: A kilometer is a kilometer, regardless of whether it is covered by a fast or slow runner.
  • Most Wins: Always choose the majority, unless someone strongly wants to defend their idea.
  • The team doing the task takes priority: For example, if it's a back-end task and everyone (or most of the back-end team) returned a 5 and everyone else (Q&A, Front-end, etc.) 8, the team wins who will Do the task.

Thanks for reading!

If you have any questions, complaints or tips, you can leave them here in the comments. I will be happy to answer!
😊😊 See you! 😊😊


Support Me

Youtube - WalterNascimentoBarroso
Github - WalterNascimentoBarroso
Codepen - WalterNascimentoBarroso

Top comments (4)

Collapse
 
jonrandy profile image
Jon Randy πŸŽ–οΈ

Estimation is a total waste of time and should be avoided

Collapse
 
walternascimentobarroso profile image
Walter Nascimento

Cool, tell me more to understand your point

Collapse
 
jonrandy profile image
Jon Randy πŸŽ–οΈ

Kinda lazy response (sorry) - but this article articulates a lot of what is wrong with estimates well...

Software engineering estimates are garbage | InfoWorld

When estimates are based on the myth of metronomic coding machines tackling deterministic work, they’re a complete waste of time. There’s a better way.

favicon infoworld.com
Thread Thread
 
walternascimentobarroso profile image
Walter Nascimento

Ok, i will read ;)