DEV Community

loading...

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

Collapse
javaguirre profile image
Javier Aguirre Author

Hello Jacob, we follow Kanban and many Scrum ideas too, but we want to focus more on delivery and quality, and we changed our most important metrics to achieve that. Once that happened, we realized story points weren't giving us positive advantages.

Thank you Jacob!

Collapse
thatonejakeb profile image
Jacob Baker

It is true to say that we've one project where we don't use story points, but we use kanban rather than scrum.

Do you work on your own product(s) or external clients?

Thread Thread
javaguirre profile image
Thread Thread
thatonejakeb profile image
Jacob Baker

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?

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.

Thread Thread
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!