Should user stories be estimated by efforts or by value it added?

Question

I read this in an answer on SoftwareEngineering.se:

Don't forget to distinguish between size and complexity in your estimating. You should estimate on size only, not complexity or difficulty. For example - adding a button to a screen should always be a '1', in that as far as the user is concerned, they are getting a button - size is very low. It doesn't matter if you actually implement it in C# (low complexity, very easy) or Assembly (high complexity, very difficult); the user story has the same size.

Is this true?

Answer 1

TL;DR

Effort and value are not correlated. Story points measure the former.

Effort vs. Value

The effort needed to implement a story may not have a direct relationship to its perceived value. A feature that unlocks a ton of value but is super easy to implement might only be a 1-point story, while a 13-point story that requires days of effort by the whole team might be of limited customer or business value.

A core feature of story points is that it allows the team and the Product Owner to determine if the value of a story is worth the effort, and if the story can fit within n iterations. If story points measured value, you wouldn't be able to use the proxy metric of effort to compare stories by project run-time, cost, or scheduling, or to estimate a time-based release plan based on team capacity.

Measuring value is certainly important, but it isn't part of the definition of a story point. In most agile systems, the value of a story (to the project; not necessarily to the business or its customers) is expressed through its ordinal position in the Product Backlog, or as an ancillary metric tracked within the process.

Story Points Measure Effort, Not Value

Story points should always be a measure of relative effort, not of value. However, practitioners can and do disagree on how much issues such as complexity, difficulty, or risk should impact those estimates.

In "What Are Story Points?", Mike Cohn says:

Because story points represent the effort to develop 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. Let’s see how each impacts the effort estimate given by story points.

Importance of Consistency in Estimation

I consider Cohn's explanation above to be fairly dispositive, and in my professional experience the combinatorial approach to effort-based estimation he describes generally results in the most consistent and reliable metrics over time. However, almost any approach to estimation can work, provided that the estimation criteria are well understood by both the team and the organization, and given that the same methodology is consistently applied throughout the life cycle of the project.

Answer 2

Estimate on size. Because size is independent of executor, and implementation approach.

Order by value. Because we want to do most valuable items first.

Answer 3

The Scrum Guide:

Product Backlog items have the attributes of a description, order, estimate, and value.

Therefore, regardless of approach, the items need both.

Answer 4

In agile you estimate the size of the story. The size is measured by story points. The story which has 4 story points has double complexity than the story which has 2 story points. We measure the complexity not the efforts and not the value. In release planning we estimate the time needed ton implement that story and then again estimate the story in sprint planning. In agile we use the term "last responsible moment" which means, do not give a commitment till the last date possible because something may change.

Answer 5

The purpose of story points are to give the team the capability to forecast and provide projections in regards to their ability to deliver software in a given time frame. Many things are factored into a story point, such has effort, complexity, uncertainty, and risk. E.g., something might be easy to do but may rely on another team, etc., but they are not a measure of business value.

Sorry for typos I'm on mobile.