How to Begin Story Point Estimating

“How long will it take for you to complete this?” — It seems to be a pretty common question that is asked of us. Truth be told, when technical team members are asked this question, our answers are so far from confident because there are so many variables that can derail a time estimate. I’m not sure about you, but I know I have been in a situation where I have given a time estimate that I couldn’t deliver on and it upset people.

What’s worse is that when you do give a time estimate, the receiving person doesn’t understand how that time estimate fits in with the rest of your workload. Just because you say 4 hours time, doesn’t mean it is going to be completed by tomorrow. So how do you estimate how long your work is going to take? Story Points!

What is a Story Point?

A story point is simply a unit of measure to determine how much effort a given task (or story) requires to be completed. The higher the effort, the higher the story point. The lower the effort, the lower the story point. Instead of estimating in absolute value (minutes, hours, days, weeks), we estimate in relative value (1, 2, 3, 5, 8, and so on). Let’s put it into perspective.

Look at these two dogs. Can you tell me exactly how much each dog weighs?

Dog #1

Dog #1 | Photo by Adam Kontor on Pexels.com

Dog #2

Dog #2 | Photo by Artem Beliaikin on Pexels.com

Of course, it would be impossible to tell exactly how much each dog weighs. Therefore, an absolute value (exact weight) is impossible to determine. Now answer this question: Does Dog #1 or Dog #2 weigh more? It is much easier to come up with an answer.

This is called relative estimation. We can use relative estimation to judge how big or complex a task is with respect to all of the tasks. The unit of estimation we can use is called a “Story Point.”

To answer our previous question, we could say Dog #1 weighs more than Dog #2 and we could assign a higher story point to Dog #1 (Lets say 10) and a lower story point to Dog #2 (3, for example).

Using story point estimation allows you to remove any emotional attachment to a task. If you tell someone that you estimate something to take you 4 hours of time, but it actually takes 30 hours of time, then what do you tell that person? They’re going to want to know why you took more time than planned and then it starts feeling like you’re coming up with explanations that are viewed as excuses. It just doesn’t feel great for either party involved.

Story point estimation removes this emotional attachment by removing the link that we have towards time.

Story Point Deep Dive

Because story points estimate the amount of effort for a given task, you have to take into consideration everything that can impact the effort. There are three major considerations that can impact the effort: Amount of work, complexity, and risk/uncertainty. Lets take a look at each one of these and see how each one could impact the task of “Folding a stack of papers”

Amount of Work

Consider the amount of work a task will take. Looking at our task of “Folding a stack of papers,” less work would be a stack of 10 papers. More work would be a stack of 100 papers.

Complexity

It’s very easy for complexity to start getting out of hand and I have found that if your requirements are not well defined, the complexity will grow over time. It’s important to have your requirements well thought out well in advance and not allow scope creep to take over. Low complexity would be folding the paper in half. High complexity would be folding the paper into an airplane.

Risk/Uncertainty

If you’re unsure on how to do something, or its your first time doing something on your own you would have more risk/uncertainty to that task. Also consider the person requesting something from you. If someone said, “I need you to fold a stack of papers but I’m not sure how many times they should be folded,” that increases the risk. Unclear expectations or scope will always drive risk and uncertainty up.

The Fibonacci Sequence

The Fibonacci Sequence is a sequence in which each number is the sum of the two preceding ones.

0112358132134
Example of the Fibonacci Sequence

You will notice that any number in the sequence is the sum of the two preceding numbers. The sequence can go on forever, but this sequence is popular in using the values for story point estimating. For the purpose of story point estimating, you can drop the first two numbers because they are redundant. Here is the sequence that I personally like to use:

123581321345589144
Story Point Fibonacci Sequence

Start Estimating

Uncertainty

To determine your story point value, you have to think about everything that can impact the task. I like to start with Uncertainty. Think about how much certainty you have in how to accomplish the task. You need to consider your own abilities and the requirements of the task.

For example, if you are uncertain about all the requirements that are needed to accomplish the task, you would want to rate your uncertainty higher. Likewise, if you are doing something you have never done before, the uncertainty would be higher as well.

Let’s say you’ve been tasked with increasing a product’s dividend rate by 0.500%. This is something you do on average 3-4 times per year so you know exactly what you’re doing. You know the exact requirement of taking the existing rate and adding 0.500% to it. You’re certain you can accomplish the task easily and you’re certain you have all the requirements, so your uncertainty is rated none to low.

Complexity

It is crucial to understand the complexity of a task. You’ll remember that we had three categories that we need to worry about: Uncertainty, Complexity, and Amount of Work. Personally, I group Complexity and Amount of Work together. The more work there is, the more complex it is. The more complex it is, the more work there is.

Assume you’re estimating the task to Implement the latest version of an application. A lot will go into this, even though the task is just a simple statement of what needs to be done. You don’t just implement the latest version of something; there is a lot of planning, preparing, and work to do to make it happen.

How about estimating our previously mentioned task of increasing a product’s dividend rate by 0.500%? The complexity of that is very simple — you’re just updating a single parameter of a product. It doesn’t even compare to how much work is involved with upgrading an application to the latest version.

Story Point Matrix

As you begin story point estimating, it’s incredibly helpful to have something to help guide you in estimating. Enter the Story Point Matrix.

By estimating Complexity and Uncertainty, you can find a story point value based on the Fibonacci Sequence.

Each estimation (Easy/None, Medium/A Little, Hard/A Lot) has two story point value possibilities. I prefer to do this because you can give an estimation of high or low. For example, Complexity can be rated as “Easy, High” and Uncertainty as “A Little, Low” — that lands you at Story Point value of 5.

You may be wondering about the story point colors. We have Green, Yellow, and Red values and each one has a special meaning. Here is the key to that:

Green Points

These are things that would be considered a quick win. A lot of your common work, fires, questions coming in, etc… would likely be green. When you’re planning your sprints, these are items that would allow you to fill out a sprint if it is lacking.

Yellow Points

These are things that allow you to accomplish things and gain momentum towards a bigger goal. These are typically realistic things that could be completed within a 2 week sprint along with other items as well.

Red Points

These values are considered Red Flags– If you’ve estimated something as a red value, then it’s a sign that you need to stop to break down your task into smaller pieces of work. Remember, the goal is to complete the item within a 2 week sprint; Anything that is red would likely take longer than the Sprint. Or, if you did finish it in the 2 week sprint, it would be the only thing you’re working on. To maintain progress on multiple things, you should be breaking things down into bite sized pieces so you can keep the momentum going in multiple areas.

*** NOTE: This is my own opinion. It does not reflect the views or represent the voice of my past, current, or future employers. ***

Like This Content? Send me a Tip!

One-Time
Monthly
Yearly

Make a one-time donation

Make a monthly donation

Make a yearly donation

Choose an amount

$5.00
$15.00
$100.00
$5.00
$15.00
$100.00
$5.00
$15.00
$100.00

Or enter a custom amount

$

Your contribution is appreciated.

Your contribution is appreciated.

Your contribution is appreciated.

DonateDonate monthlyDonate yearly

What is a Code Review?

Code reviews allow you to ensure you’re putting forth the best product possible. They’re very beneficial because they help:

  • Detect and remove defects.
  • Ensure requirements are met.
  • Identify potential improvements (code syntax or efficiency for example)
  • Determine progress in a project
  • Reduce development time
  • Reduce testing time (because of less defects).

It is important to know that the sooner a defect is found, the cheaper (money or time) it is to fix. For example, if a defect is found during the development stages before it hits the Quality Assurance team, you’re reducing the amount of time QA needs to spend on that particular issue. A more extreme example would be a defect goes undetected and makes it into a production build. What could have been a quick and simple fix in earlier stages of development has now become a high-risk fix because you need to apply the fix to the production environment.

But, what is a Code Review?

A code review is where you get eyes on your code to receive feedback and suggestions on how to improve your written code. It is absolutely something many dread. It’s hard to have eyes on something you’ve created and listen to feedback, no matter how harsh, and apply it to what you’ve created.

No matter your experience level, you need to always remember a code review is in place to ensure quality in the product and, most importantly, quality in the programmer (you!). Try not to take offense to any suggestions — Simply evaluate the suggestion and either agree or disagree and express your opinion to either apply that suggestion or why you don’t feel it should be applied.

Informal Reviews

If you’re part of a small development team, this is probably the type of code review that will likely happen. Sometimes called a “Desk Check,” an informal review is a just a casual meeting between two developers to review written code or functionality.

With a desk check, there isn’t typically any advanced planning or preparation. Typically, these are started by saying, “Hey Sally, can you come look at this code with me?” and then Sally comes over to look at code. Welcome to a desk check.

Because there is no formal planning or preparation, these types of reviews are not fully productive. Sure, you’re going to uncover some things, but there will be things that are missed because you just aren’t thinking about it.

Instead of doing these impromptu, I recommend that you try to formalize the desk check/informal review. Make it more… formal! You can do this by scheduling time to do a review with your coworker(s) and giving your coworker(s) a little time prior to the meeting to review the code. To make it really impactful, formulate a list of things to check against to ensure your code base meets the standard of your company.

Formal Reviews

Formal reviews are pretty similar to informal reviews except there is more structure and more people participating. One of the biggest benefits to a formal review is that you can bring together senior developers and junior developers which allows junior developers to see how a senior developer approaches situations. On the flipside, the senior developer can be reminded of more simple solutions to problems. Juniors are eager to learn and Seniors can sometimes overcomplicate things that can be simple.

Another huge benefit to formal reviews is that because you have multiple sets of eyes on the code, you will have multiple people who understand this area of the code or product. There is nothing worse than only 1 or 2 people understanding how something works only to have them leave and the remaining team has to devote time to understanding that area without any guidance.

Each formal review should follow these guidelines:

  1. Limit the review to 3 and 5 people.
  2. Everyone should have time to prepare (and they should) for the meeting. Preparing should be no more than 2 hours in time– even so I feel that 2 hours is pushing the limit.
  3. The review meeting should be less than 2 hours.

The focus for the review should be a small piece of the overall software. We aren’t trying to review the entire code behind a given piece of software. To help get everyone up to speed on what the given code does, provide context on how this code interacts with the rest of the software by presenting a quick walkthrough. Regardless, by narrowing the focus, you will have a higher likelihood of uncovering errors.

When to Review

An informal review is informal. These types of reviews happen fluidly and don’t have a set time. I do, however, recommend that you set some time aside to review code as it is completed, though.

For a formal review, there is a process, and it typically goes like so:

  1. Developer will write code and feel they have a finished piece of work.
  2. Developer informs the project leader that code is complete and ready for review.
  3. Project Leader will contact a Review Leader, who evaluates the code for readiness, creates copies of product materials, and distributes them to 2 or 3 reviewers for advanced preparation.
  4. Each reviewer is expected to review the code making notes and becoming familiar with the work that was created.
  5. Project Leader schedules a review meeting and establishes an agenda.

What Happens During the Review

Typically what happens is the code is reviewed by all meeting attendees and suggestions are made. By the end of the meeting, the group will have a decision to make with 3 outcomes:

  1. Accept the written code as written with no modifications. (Rare)
  2. Accept the written code provisionally with minor modifications and no additional review (Common)
  3. Reject the written code due to severe errors and another review will be required (Uncommon to Common)

There is a lot more that goes into the meeting, but that is a topic for another day.

*** NOTE: This is my own opinion. It does not reflect the views or represent the voice of my past, current, or future employers. ***