Changing from time estimation to story points

Kirsty Fleming's picture

I'm desperately looking for a bit of help! We are a small scrum team who recently turned agile (yay). The previous pm manager preferred using time estimations which was easy for pm's, not the agile-loving dev team. I want to teach my team how to switch to story point estimation and the major concerns of the team are - How do we explain cost to clients per sprint using points? Do we just take the budget total, divide into sprints (based on hours in a sprint) and cost this for a big project?


I have a very reluctant team so any help would be greatfuly appreciated!




2 Answers

Johanna Rothman's picture

Kirsty, think about two kinds of estimation. One estimation is for an order of magnitude, for management. One is specific for the team, "What can we do in this next iteration?" (I assume you work in two-week iterations.)

Now, the problem is this: Any kind of estimation you do with a new team, or on a new project where you don't know the domain is suspect. You need to provide that kind of an estimate with some uncertainty. I like 3-point estimation or percent confidence. Managers don't like this, but that's what they need to plan. 

If you want to plan what you can do in an iteration, why use story points at all? Why not just count stories? When you count stories, the PO has an incentive to make each story smaller. The team has an incentive to work together to move that story to done. 

I'm not talking about tasks, I'm talking about a story that has value to a customer.

As for "when will this project be done?" only the PO can answer that question. What is an MVP? What are the project's release criteria? If the PO defines and the team delivers MVPs, you might be able to end the project early. And, the PO can change what goes into the next iteration, to guide the product growth.

When you use features (or stories), what the customer buys, you have these benefits:

  • You can measure the cycle time for your features. You can then provide an average cost per feature. (Take the daily run rate for your team and use cycle time. A 2-day feature costs 2x the daily run rate.) This also incents the customer to work with the PO to create smaller stories.
  • You can work with the customer to explain what "average" means, which is not every feature, but the average. Some features will cost more, some will cost less.

I don't know how to use story points with customers. I suggest to all of my clients that they not use story points. Instead, I recommend that they use cycle time and measure the average cost for a feature, if they need to provide cost/schedule information. 

The big question I have is this: Can your team deliver a story every day (or every other day)? If not, your stories are too big and your estimation is off. Reduce story size and estimation becomes irrelevant. You count, not estimate.

Yes, the PO has a bigger job. That's the point of agile. We move all the "what and when" questions to the PO so we can deliver features on a regular basis. 

Let me know if you have more questions.

Mitch Goldstein's picture

Believe it or not, that is the heart of agile project funding. If you can make a stab at what your team can produce in a week, the cost is the cost of the team and the revenue is the value created in an iteration.


Important to note: estimation is always done just-in-time, so estimating work that is further away will be less accurate. If your team estimates honestly and transparently, over time you will get better and better.


The temptation to try and estimate in TERMS of time is not recommended - try to think in terms of complexity. You can think of complexity as being roughly linear with the number of things you have to DO in order to finish a story. This very roughly equates to time, but thinking in terms of time alone has been widely proven to be much less accurate.

Recommended watching for your team: Cost of Delay: Theory and Practice



AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.