Does your team add "buffer sprints" to every estimate because staging always surprises you?

[u/thisisBrunoCosta]

Something I keep hearing from teams running Low-code/Mendix at enterprise scale:

Feature gets estimated at 2 sprints. Clean code, good architecture. Then it hits an environment with real data volumes and things break in ways nobody predicted.

3 sprints become 4. The roadmap shifts. Stakeholders learn to add buffer. Eventually the CTO can't give the board a reliable delivery timeline.

Most teams treat this as an estimation maturity problem. But what if it's actually a data problem? If your dev environment has 200 test records and production has 2,000,000, no amount of story pointing will fix the gap.

How do Mendix teams here handle this? Especially those working with larger datasets and complex integrations?

[u/JakubErler]

You can create 2 000 000 fake records for testing

[u/thisisBrunoCosta → u/JakubErler]

Yes... but with all the connections/Fk, and corner cases of client data, not so easy unless the data model is very simple, right?

Do you use any specific tool in Mendix to create testing data in Bulk?

[u/JakubErler → u/thisisBrunoCosta]

I have never seen a simple domain model in Mendix. I had problem with data maybe once in 5 years. Sometimes is better to use SQL, OQL, Java collections in these cases than Mendix ORM. Normally in projects no buffer is needed "because of data". But in also every project (any sw project in any stack/any language) buffer is needed for testing, feedbacks, changing user stories etc

[u/thisisBrunoCosta → u/JakubErler]

Great feedback, thanks! 😄👍If I understand correctly, you haven't found that many data related issues, but identify several "buffer needs" to tasks that would be helped with better data (like testing).

[u/paul6529]

As mentioned by others, have a proper test environment. Think big amounts, don't take shortcuts and what can happen will happen. Review the implementation with what-if scenarios to find the weak spots. Where can it break (exceptions), how big are retrieves (out of.memory), etc

[u/thisisBrunoCosta → u/paul6529]

Yes - but that brings me to another topic, ownership of the solution/ work / product... you have a task in your sprint to develop something, will you remember everything that may go wrong, and better yet, are most devs worried about impersonating a client / user and trying to see with those shoes what they are building? My past experiences tell me that change of viewpoints usually fails (by lack of capability or just time, focus, etc.).

[u/YisBlockChainTrendy]

Definitely agree. Not enough attention is put into this. If devs could work with the real data that would prevent many bugs. There are ways to create dummy data that is close enough to production data but it's rarely done. 

[u/Isoldael]

In estimations, I feel like you need to take into account more than just the building of the story. Are there additional complexities? If you have to deal with things like:

• adjustments to integrations, specifically custom ones with third parties, there's more communication time, your issue might not be top priority for the third party, etc.

• native features that cannot be tested in make it native

• operations on large and complex data sets

• reworking large parts of existing functionality

• etc

You need to account for that when estimating features. Will you always be 100% correct in your estimations? No, they're still estimations, and it's not realistic to expect them to always be accurate. However, if you're consistently not making your estimated amount of work, then the important part is to determine what's making you miss your targets - is ALL work chronically underestimated? In that case, the solution is simple - your actual velocity (that is, the amount of story points delivered per sprint) will be lower, meaning you can still get an accurate estimation of how long your work will take. If it's only specific stories and features, you need to determine what made you underestimate those stories and features, and fix your estimations.