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!




1 Answer

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.

AgileConnection is a TechWell community.

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