Wonder how we point stories? Well wonder no more! This article talks about how we point stories at STORD...and also covers the WHY

Why point stories?

Good question! We want to provide point estimates instead of time estimates (even though points are a proxy for duration, bear with me here) because humans are bad at estimating but good at relative sizing.

If you put 100 dogs in a room, then asked 5 different people to sort them into buckets of extra small, small, medium, large, and extra large – you'd likely get about the same groupings for each person.

That's because people are good at relative sizing, which is why we use the Fibonacci sequence. The difference between a 1 and a 2 is clear, and a 2 and 3...but a 3 and a 4? So the next sequence is 5. A difference between a 3 and a 5 is clear. The next sequence is 8. A difference between 3, 5 and 8 is clear when you compare sizes of things.

If you spend so much time estimating, then you’ll have wasted time that could be spent actually doing the work, and the estimates will likely be wrong anyway (because humans are bad at estimating, but good at relative sizing).

Here’s a list of benefits for pointing work that will deliver value:

Allows us to set attainable goals, and strive to accomplish them
Helps set expectations for how many sprints it might take for a team to accomplish an epic of work. This helps with planning – the product and UX team know when they need to focus on getting the next epics and stories ready
Let’s the team establish a velocity based on a level of consistency when understanding the work to be done to deliver against the value of the story (it typically takes a new team a few sprints to establish)
The team can get aligned on what it will take to get something ‘done’ by agreeing on the points to complete it.
It can uncover risks or issues when estimates are higher than expected – and uncovering such things early on is a good thing!!

Here what points are NOT:

a time estimate that team must hit

How do you story point?

Because story points represent the relative size of effort to complete a story, a team’s estimate must include everything that can affect the effort. That could include:

The amount of work to do
The complexity of the work
Any risk or uncertainty in doing the work

When estimating with story points, be sure to consider each of these factors.

Here's an example using a simple HTML form.

You have story that requires building a form with 10 fields, and they are all text inputs – this is a pretty easy effort, no complexity to speak of, and low risk
Now take that same 10 field form, but instead of all text field inputs, now the form has a file-upload widget, a slider, some checkboxes, a text area, radio boxes, and textfields. Okay, so now the complexity has gone up and there is likely some risk in how these fields will interact.
Let's go back to the same simple form with all text field inputs, but now we have 100 fields! The complexity didn't change, there could be some risk with the browser even rendering that many fields, and the level of effort surely went up to deal with 100 fields instead of 10.

That's why a story's SIZE should be determined by its:

Level of effort
Complexity
Uncertainty/Risk

Remember the earlier example where we were sorting all the dogs in a room?...think of size in that literal way, like the size of the dogs. When the team points a story of 3 points...and then another story that's 3 points. Would say they are the same size? Try to think of the comparison in these physical terms.

Hope that clears up how STORD does story points

Ready to help us build a Cloud Supply Chain?

We have a great team and we are making great strides. We are also experiencing triple digit, year-over-year growth due the acceleration of ecommerce by COVID. Having a Cloud Supply Chain gives companies key business capabilities – speed, flexibility, and cost savings. Please checkout our careers page to see how you can help us!