Can story points remain constant between the initial estimate and later planning sessions?

Question

Background

• We have a bunch of epic stories.
• We have a fixed term to do the project.
• We have to get approval from a project board.
• We don't know the velocity of the project team yet.

The project board wants to estimate epics with story points and then split those epics into smaller stories where the points all add up to parent story. Variance in later estimates is punishable.

Question

If I hold an estimation session for a dozen large epic stories using the fairly large numbers, 20 points and upwards, this number comes out to 400 points. I later break those epics down into smaller stories and estimate them for an increment. I am under pressure from my project board to have very little variance in these later estimates. For example, the smaller stories should all add up to the estimate of their 'parent' epic, and all the smaller stories should continue to add up to 400.

I have my own views on this, but wonder:

1. How desirable is this process from the team's point of view?
2. Is it a realistic expectation?
3. Are story points related at all between the initial estimate and later sessions?

What do other people do in these situations? I'm more than happy to clarify any of the points if it will help.

Answer 1

The variance here in punishable.

That is unfortunate. It is imminent that you will be punished because it is certain that there will be variances. Hoping or trying to have a near zero variance, or zero variance, is to suggest it is possible we can predict the future accurately and precisely...which we cannot. Accurate Estimates is an oxymoron.

First you need to understand there is a real difference between an estimate and your planning values. An estimate is ALWAYS a range and your planning value is the number you are hanging your hat on. In other words, you estimate that this task will take from 10 days to 25 days. Your planning value is 19 days. See the difference?

Your goal here is to choose a planning value where most of your probability is behind you and not in front of you, but where you don't build in too much wasted fat. The choice needs to be consistent with your organization's risk tolerance. Since you are in a zero variance culture, that implies not a lot of risk tolerance so you are going to be on the fat side of your estimates. It's expensive but safe to operate that way.

But I think your real challenge here is training your organization about the realities of estimation, aleatory risks, and the unrealistic expectation of this notion of zero variance.

Answer 2

On a given project, estimates should get better as experience team gains experience with and knowledge of the particular project. This will cause estimate to change. As you break things down you should get better estimates which may or may not be equal to the estimate for the larger package. If there is low tolerance for variance from the estimate of the original, you may want to provide the project board with scaled estimates. Track the actual totals so that you are aware what the scaling is hiding. If it is hiding schedule slippage or variance is otherwise high, the earlier you come clean the better.

In many industries, it is possible to plan very precisely. When you are building another unit when you've built hundreds, thousands, or millions of before, it is easy to accurately estimate how long it will take. In these cases, a known process is being repeated and there is no design, experimentation, or rework required. Testing if required, is to ensure quality is maintained, and rarely results in rework.

Building software is an entirely different process. Unless you have a poor process, each unit consists mostly of design, experimentation, testing, and rework. All of these steps are difficult to predict.

• Good processes and understanding of the problem can reduce failures in testing and resulting rework.
• Appropriate standard practices can limit experimentation.
• Expertise in the subject matter and tool set can reduce experimentation as well.
• Standards and appropriate components can reduce the all of these factors.

In the end, you should be building one-off components. These don't have the time certainty, that is found producing the next unit of a series.

Ask the project board if they would accept a similar lack of variance in the time they take on their task.

Answer 3

The answers given so far are good. I'd add one thing: treat all estimates as immutable.

You never update an estimate. You create a new estimate.

There is never "the" estimate.

There are "the estimates" and "the most recent estimate".

However, since your board have tied estimation to reward and punishment, they have defeated the purpose of estimation and destroyed information. It doesn't really matter what estimation policy or process is used, because the board have created a direct negative incentive to subvert all estimates.

Your most rational strategy now is to quit, your second most rational is to engage in aggressive sandbagging, haggling, lawyering and other CYA activities.

As for:

For example, the smaller stories should all add up to the estimate of their 'parent' epic, and all the smaller stories should continue to add up to 400.

This is not going to happen. The Unpacking Effect shows that estimates, when broken down, grow larger.

Answer 4

TL;DR

Your board is out of their collective gourds. Estimates are not guarantees, and the precision of estimates in any process (but especially in iterative processes like Scrum) is a function of both inevitable change requirements and a varying cone of uncertainty.

Estimating Epics

The purpose of estimating epics is to give a rough outline of the project schedule, and allow stories to be prioritized to achieve optimal value for each milestone or target ship date.

By the very nature of epics, the cone of uncertainty is extremely large and the initial estimates (which are not guarantees) will not have the precision of the story-by-story estimates that are done at the start of each Sprint.

Project estimation is a projection, and a guideline for measuring variance. The project schedule can and should be subject to the same inspect-and-adapt cycle as the rest of your process. The board can then use the Theory of Constraints to adjust schedule, scope, or resources as they see fit.

Inspect-and-Adapt Scheduling

Are the story points related at all between initial estimate and later sessions?

Yes and no. Ideally, while there may be variance between the initial projection and iteration-by-iteration feature delivery, the variance should fall within some reasonable order of magnitude. If it doesn't, which is not an uncommon occurrence, then it is simply evidence that the initial estimate was wrong and should be revisited.

Another way of looking at this is that the initial estimate is a baseline against which you will identify variance. What you choose to do about that variance is up to you. In a well-run Scrum project, one might:

1. Re-estimate the entire Product Backlog in light of what is currently known.
2. Re-estimate the project schedule based on the new backlog estimates and the team's current velocity.
3. Re-prioritize the Product Backlog to squeeze as much value into achievable release dates as possible.
4. Fail early, if the project's objectives cannot be met.

Identifying Variance: Effective Control Isn't a Sin

The real problem here is cultural. You have a command-and-control project board that is looking at iterative development as a silver bullet. It isn't.

Identifying variance is a desirable outcome of an effective project control. Punishing the messenger does not result in transparency or visibility; it can only result in CYA behaviors such as:

• Excessive padding of all estimates.
• Project dashboards that are always green, right up until the project results in an irremediable epic failure.
• Ponderous change management controls designed to prevent any changes which could increase the cone of uncertainty by even one iota.
• Blame-shifting, including finger-pointing to poor specifications or vague project criteria, neither of which will result in a usable product.

The purpose of comparing your current progress against an initial or updated scheduling estimate is to identify that variance. If variance is punished, then it will not be identified. Q.E.D.

Answer 5

"Variance in later estimates is punishable."

OUCH!!!!

There are many great answers here but I want to focus on this issue as this type of attitude kills projects, teams and productivity.

Estimate is exactly that ... an estimate. It is not an actual. The world of software development is full of complexity and uncertainty and this should be accepted by business. The management need to be asked the question of "What are you going to do to mitigate against estimation that exceed?" In Scrum, we teach teams not to take on risk that is for the business, these are around time, money, budget.

Teams build software and that is their skill. They are not project managers, nor are the estimators. They can help give guidance to estimates, but it is simply that.

I often challenge management around sales and budgets. Do they accurately estimate their future sales and budget figures to the day? It is NO; so if they cannot estimate as management, how on earth do they expect other people to estimate accurately?

I recommend getting a skilled coach in to help educate your management on estimation as there are many, many factors that are to big to discuss here. The coach should help change the mindset of your managers.