DEV Community


Discussion on: Why we ditched story points to be more value-oriented

javaguirre profile image
Javier Aguirre Author

Interesting! I've yet to have a client give carte blanche to just get on and build their product without some form of estimate, as much as that estimate is usually (read: always) wrong one way or the other, and usually I use story points after breaking down stories to guesstimate rough time and cost at that point in the project. True to say this is constantly revised as the project goes on with each iteration.

How do you go about this with clients?

I understand you. We have the same problems. In our case it's more about scope rather than carte blanche, in software having closed budget projects is usually sad for all the parts, the expectations are challenging to fulfill from the client and our point of view. So what we say is let's see what features we want to build and make an estimation in sprints, we need two developers full time and a product owner part-time (for example) per sprint and we charge you that.

Of course, this estimation won't be written in stone, but we'll charge you only for that sprint and not a big release, so it's more flexible for the client too, and the client can decide to prioritize other features depending on us finishing faster or not. Sometimes they want to prioritize different features depending on new metrics, so this approach is also more convenient.

When we start working with someone we explain we use user story mapping, we split features and stories and estimate from there, we prioritize and usually have a Sprint Zero to deliver the first product backlog.

Don't get me wrong, I really like the idea of delivering (and billing) quality and value over time but the business world doesn't seem to be there quite yet in my experience.

These discussions are great to improve! Let me know if you want to discuss more about it. :-)

Thank you for your comment!