Parameters allow you to prompt users for one or more inputs that will be passed into a build. For example, you might have a project that runs tests on demand by allowing users to upload a zip file with binaries to be tested. This could be done by adding a File Parameter here.
Or you might have a project that releases some software, and you want users to enter release notes that will be uploaded along with the software. This could be done by adding a Multi-line String Parameter here.

Each parameter has a Name and some sort of Value, depending on the parameter type. These name-value pairs will be exported as environment variables when the build starts, allowing subsequent parts of the build configuration (such as build steps) to access those values, e.g. by using the `${PARAMETER_NAME}` syntax (or `%PARAMETER_NAME%` on Windows).
This also implies that each parameter defined here should have a unique Name.

When a project is parameterized, the usual Build Now link will be replaced with a Build with Parameters link, where users will be prompted to specify values for each of the defined parameters. If they choose not to enter anything, the build will start with the default value for each parameter.

If a build is started automatically, for example if started by an SCM trigger, the default values for each parameter will be used.

When a parameterized build is in the queue, attempting to start another build of the same project will only succeed if the parameter values are different, or if the Execute concurrent builds if necessary option is enabled.

See the Parameterized Builds documentation for more information about this feature.