Don't Just "Work the Story." Work the Right Story!
Your current user story reads:
As a portfolio manager,
I should be able to select list of models from the list,
so that I can create a portfolio.
On the one hand, this story doesn't define a need to select all the models, just "a list" of them. In that case, how many they can select is left as an implementation detail that should be negotiated between the Development Team and the end users. The feature can then be improved or refined over time as needs change.
On the other hand, if selection of all models as a functional requirement for the product, then your stories may need to be rewritten to capture the actual needs of the user and the non-functional requirements this imposes on the current system. While I have no way of extrapolating your actual use case from the original question, consider the following example:
As a portfolio manager,
I want to be able to select 2,000+ models all at once
so that I can run complex data analytics on exported data.
This is a more useful story in that it provides a more accurate sense of the size of the selection the user wants. It also improves on the original by providing a context for the story, so that the team can more accurately plan and estimate the effort to meet the need. It also provides a baseline for collaboration with stakeholders, as there might be reasonable trade-offs that can be made in either the use case or the implementation of the feature.
Once you are sure you have the right story from the portfolio manager perspective, you might need some additional stories that capture the engineering or administrative perspective. These may be functional or non-functional requirements, but in any case represent features of the product that should be managed like any other. For example, assuming this is a web interface to a typical database:
As a site administrator,
I want to allow users to export all models in the data set without a large performance penalty
so that complex analytics can be offloaded from the the application itself.
By forming a theme around these related stories, you can work iteratively on the functional and non-functional requirements over more than one Sprint while keeping stories small and negotiable per INVEST criteria.
Most importantly, by capturing the right level of detail about what the product's users really want and why, you enable the Development Team to validate assumptions (e.g. does a user really need to select 2,000+ models within a web UI?) or offer alternative implementations (e.g. data exports) that wouldn't necessarily occur to a non-technical person.
Always remember that user stories are conversation placeholders, not specifications. Write user stories to capture the essential perspective and context of each story, and then turn the creativity of the Development Team loose to collaborate on the implementation details so that you don't over-constrain the solution space.
That's the "secret sauce" that makes agile frameworks so effective: an open-minded, collaborative approach to crowd-sourcing solutions; optimizing for work not done; and searching for the simplest solution that meets the immediate need, leaving future refinements to the future.
