Having trouble with story pointing...

It sounds as though the team understand the work which is likely to be involved in implementing the item, and that estimation has therefore served its purpose.

What problem are you trying to solve or avoid by challenging their estimation technique? Do you suspect that Sprint Planning may be compromised, for example? If so, how have you substantiated any such concerns to the team?

Because a story shouldn't take more than 3 days to complete, and on top of that, if they get a complex assignment and it takes 1 day to complete, that shouldn't be worth more points than something that took them 7 days to complete but has a 3rd of the points... 

The way I look at it is if we're making a skateboard, and it takes us 7 days to make the nuts to screw on the wheels but it takes us 3 days to build everything else, then the nuts shouldn't of been a 2 complexity and the rest a 34... 

Does that make sense?

I'm having developers tell me that a story is not complex at all, we're using the fibonacci sequence so they're saying it's worth 2/3 points. Yet, they're telling me the work will take them a week to complete...

As a Scrum Master, you should be encouraging the team as much as possible to estimate based on their effort and complexity, and not to factor in dependencies and wait states that may lengthen the time to complete an item, but have little if any impact on the team's effort.

It seems that from your example, the team is relatively estimating the item.   That is good, and that is all they should be concerned with, as that is all that is really needed to support their planning and forecasting efforts.   

There may be a wide number of factors that cause a small item to last a longer than expected duration, and those causes (constraints, dependencies, etc) should be discussed and potentially remedied in the teams' Retrospective.

However, if the team is relatively estimating small for items that actually take the team 1/3-1/2 of a sprint to complete, they should be made aware that their "scale" isn't really accounting for items that can be completed in much shorter time frames.

I guess I don't understand how effort and time don't end up being the same thing? It's my understanding that we never get better at guessing how much time we'll dedicate to an effort, but the level to which it is complex we can. The entire purpose of velocity is to show what a team is capable of doing in a given time. If we track it by effort aren't we just turning it into a capacity management tool?

I guess I don't understand how effort and time don't end up being the same thing?

A low effort item might be frequently returned to and so have a long elapsed time, while a shorter one might be comparatively intensive in terms of effort and thus more wearing on the team. They may reasonably take this into account when estimating work and how much they are prepared to take on.

The way I look at it is if we're making a skateboard, and it takes us 7 days to make the nuts to screw on the wheels but it takes us 3 days to build everything else, then the nuts shouldn't of been a 2 complexity and the rest a 34... 

Is the team completely capable of delivering the item that they are estimating, or are there delays or outside dependencies that affect the delivery timeline?

Using your skateboard example, does the team have all of the capabilities to produce an entire skateboard, or are they dependent upon other teams for various parts or assemblies?   If they have to wait on others, that could significantly affect the timeline, even though the actual team effort is minimal.

If they have all of the capabilities, then might there be wait states and/or delays in the creation/assembly process (ex: wait time for the plastic wheels to cure and harden)?

Relative estimating is a lightweight approach to capture actual effort/complexity, and allocate a numerical value to it.   To draw a correlation to t-shirt sizes, they're just placing the item into one of 5 buckets: XL, L M, S, and XS.

Dependencies, organizational constraints, and team constraints can easily affect the duration of a task.   For example, if there is only one person on the team capable of creating the nuts, but they're out sick for a few days, completion of that very minor item completion is delayed because of a team constraint.

First, I think it's important to mention that Scrum does not define what story points are, how they are used, or if they are even used at all.

It's a common practice, and is often helpful; but there are other options, such as #NoEstimates, ideal days/hours, or just plain old time.

This is a particularly relevant topic to me at the moment, because a developer in one of my teams recently expressed having to give a low estimate for something time consuming because he's been told that story points must be a measure of complexity, and the task takes a long time, but isn't complex. For now, I am not interfering with the team's method of estimation, but I do plan to have a session with the whole team soon to work out whether their current definition of a story point is helpful, and facilitate a change if it's needed.

I think it's important to understand why estimates exist in the first place.

I believe their main uses are:

• Help the Scrum Team identify misunderstandings about the scope of a Product Backlog Item
• Help the Scrum Team refine and split Product Backlog Items to reduce the cycle time, and "maximize the work not done".
• Help the Product Owner re-order the Product Backlog in order to maximize the value delivered by the team.
• Help the Product Owner forecast likely completion dates over the course of multiple Sprints
• Help the Development Team forecast the work that it can complete within a Sprint

Perhaps there are other reasons that I've not thought of.

Given what we want to use estimates for, what form of estimation works best for the Development Team, in order for empirical decisions to be made?

If the Development Team choose to estimate complexity, that's valid. If it doesn't work for any of the reasons we want to have estimates, the Scrum Team can discuss it (perhaps in a retrospective), and try to find a better system.

If the Development Team feel it's better to measure effort, work or time, that's also fine. My main advice in such a situation would be for team members to pick a value that represents their estimate for the relative effort/work/time of the whole team.

For instance an experienced software developer shouldn't estimate lower if they think they can do the job faster than their colleagues, and a frontend developer, backend developer, and QA (if such specialisms exist) should estimate for the collective effort/work/time for the entire team to get the Product Backlog Item to a "Done" state.

Here's an opinion from Mike Cohn, and it contains a good example about how estimating complexity might not be helpful: https://www.mountaingoatsoftware.com/blog/its-effort-not-complexity

I agree with Simon  and was coming to say just that. Jon Joe you don't get to dictate how the team does estimation the team does that. They are the experts and it's in their wheel house of duties. UNLESS you are serving the double duty of Scrum Master and a developer and are doing some of the work. Even in that instance estimation is a team activity not a single member activity.

Story points are always a relative estimate of the overall size of a story. It is a function of {complexity, work involved and inherent risk} in developing a story. Relative sizes matter and not absolute values. You don't care if a story is sized 3,5 or 8? But when you size a story to 8, you as a team should be able to explain why it was sized to 8 and relative to which story or a combination of stories?

Assume you have a story :

S1 - medium complexity 

S2 - simple 

S3- high complexity

S4 - medium complexity

As a team you discuss and relatively estimate S2 as 3 points. It's a TEAM estimate.

Then relative to S2, where does S1 stand? If S1 is estimated as 8, it simply means that S1 is almost 3 times more complex than S1. As a team it has to be validated.

If S3 is estimated 13( using the relative estimates of S1 and S2). It means that S3 is 1.5 times more complex than S1 and approx 4 times more complex than S2.

Now when you estimate S4 - using the above triangulation method, where does it stand from a relative estimation perspectives using any combination of the estimated S1, S2 and S3 stories?

A story estimated as 10 points is twice as big, complex or risky as a story estimated as 5 points. A 10 point story is half as big, complex or risky as a 20 point story. What matters are the relative sizes/values?

If the story isn't complex, but takes a lot of time to complete that is a huge sign that there is something impeding the team from moving forward...now the question is, what is it?

Hmm...this is a 2 point story, but it's going to take a week to complete it, why is that?

Oh, it's because we only deploy to the QA environment once a week? Why do we do that?

Oh, because it takes two days to complete regression testing, so we need to deploy to QA in batches? Why does it take so long, do we have automated tests?

Oh, we have automated tests, but we don't trust them? Why's that?

Oh, we haven't been maintaining our automated tests as part of our Definition of Done AND we have dependencies on other teams so the automated tests we do have frequently fail and we don't have a clear understanding as to why?

Well...I think we have something we can work on improving now don't we?

Personally, I'd argue that your story point estimation by relative complexity is doing exactly what it's supposed to do.