Managing sprint scope
One of the more difficult things to do during a Scrum sprint (or an iteration in general) is to manage the scope throughout the sprint. With the team working closely with the business to ensure we actually meet the business expectations there is a fine line between incorporating feedback and taking on more work.
Granted, without a detailed specification there is room for interpretation and it’s in the nature of an agile development (and one of its many advantages) that great ideas pop up as we can see a first cut on a particular functionality. However it is also important to not make the mistake of confusing the new ideas with the original sprint scope. You may be able to implement some of the ideas right away - depending on how much work is involved to make it happen. But often these ideas enhance the functionality you set out to deliver - in this case you are mostly better off to add them as backlog items and defer them to a later sprint. You might even find out that if seen in the context with the remaining backlog items they become less important and eventually aren’t implemented at all. If they are truly great ideas then surely the business will prioritize them into one of the next sprints.
If you take a four developer team and a four week sprint in which the team works closely with business representatives as an example it is reasonably to assume that two of these ideas (assume on average maybe 6h/idea) per developer come into play. Then maybe there are a few little other things (~1h work) your team is asked to do that is not directly related to the sprint goal and suddenly there is a full week of work that you haven’t planned for. It’s easy to miss a sprint goal if you keep doing this.
One trick is to consider implementation details purely from a business value point of view. Take for example a screen in an application that is used in a data entry process but also in a work flow. If your sprint scope includes the data entry but not the work flow then the screen is completed once it implements the data entry functionality - even if the team has to go back and modify the screen to make it work also for the work flow. With little things coming up ask yourself the hard question if they are necessary to complete the sprint goal! If not they go into the backlog and will be prioritized in the next sprint planning session!