By the sounds of it you have isolated this issue to the developer and that (imo) means you need to modify your process to ensure issues like this don't continually or modify the interactions with this developer.

On a side note, don't count out the tasks / stories on the board as being a potential cause of this scope creep.

Scope creep is resulting from a poorly understood user story:

Have you INVEST'ed in writing good user stories?

Do your stories have clearly defined acceptance criteria (Acceptance criteria are the requirements that have to be met for a story to be assessed as complete) ?

If your answer to these questions is yes, then you may want to talk to the team about modifying the process of when a team member picks up a task from the board to include a a discussion with the Product Owner (or whom ever is representing the PO). This discussion is simply intended to to make sure the developer has a clear understanding of what "Done" means.

Scope creep is a symptom of the developer and not the process:

You need to have a candid discussion with this individual. They need to know that the scope creep they are adding to the stories they work on is affecting the project and the desired outcome of the story. If they have "ideas" you should encourage that they bring them forward but not blindly code them into the story.

If their behavior does not change after having this discussion then I would remove them from the team.

Scope creep is a symptom of the teams definition of done:

How are stories accepted as done on your team? By the sounds of it you are saying that when the story is moved to "done" is has a large amount of bloat added to it, but it is still moved to done.

On any team I have worked on, if the "bells and whistles" did not add to the user story (or sometimes even if they existed) I would have rejected it and moved it back to in progress until the acceptance criteria has been met for that story. You do this a few times and it become pretty evident to individuals they should be developing the bair minimum that meats the stories acceptance criteria

Scope creep is a symptom of the individuals design:

Is design being vetted by the team prior to a developer coding on the story? If not, this could be something you add to your process. Be sure to include the PO or PO representative to ensure that the proposed design is the bare minimum to meet the stories acceptance criteria.

By the sounds of it you have isolated this issue to the developer and that (imo) means you need to modify your process to ensure issues like this don't continually occur or modify the interactions with this developer.

On a side note, don't count out the tasks / stories on the board as being a potential cause of this scope creep.

Scope creep is resulting from a poorly understood user story:

Have you INVEST'ed in writing good user stories?

Do your stories have clearly defined acceptance criteria (Acceptance criteria are the requirements that have to be met for a story to be assessed as complete) ?

If your answer to these questions is yes, then you may want to talk to the team about modifying the process when a team member picks up a task from the board to include a discussion with the Product Owner (or whom ever is representing the PO). This discussion is simply intended to make sure the developer has a clear understanding of what "Done" means.

Scope creep is a symptom of the developer and not the process:

You need to have a candid discussion with this individual. They need to know that the scope creep they are adding to the stories they work on is affecting the project and the desired outcome of the story. If they have "ideas" you should encourage that they bring them forward but not blindly code them into the story.

If their behavior does not change after having this discussion then I would remove them from the team.

Scope creep is a symptom of the teams definition of done:

How are stories accepted as done on your team? By the sounds of it you are saying that when the story is moved to "done" is has a large amount of bloat added to it, but it is still moved to done and "accepted".

On any team I have worked on, if the "bells and whistles" did not add to the user story (or sometimes even if they existed) I would have rejected it and moved it back to in progress until the acceptance criteria had been met for that story. You do this a few times and it become pretty evident to individuals they should be developing the bare minimum that meets the stories acceptance criteria

Scope creep is a symptom of the individuals design:

Is design being vetted by the team prior to a developer coding on the story? If not, this could be something you add to your process in the form of a design session. Be sure to include the PO or PO representative to ensure that the proposed design is the bare minimum to meet the stories acceptance criteria. Note, that this design session could simply be an ad hoc discussion in front of a whiteboard.