Can work committed during Planning be added and not be treated as Scope change.
The Scrum Guide states the following: "The Development Team usually starts by designing the system and the work needed to convert the Product Backlog into a working product Increment. Work may be of varying size, or estimated effort. However, enough work is planned during Sprint Planning for the Development Team to forecast what it believes it can do in the upcoming Sprint. Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less. The Development Team self-organizes to undertake the work in the Sprint Backlog, both during Sprint Planning and as needed throughout the Sprint".
Does this mean that during the Planning meeting the DEV team can take only one Spike and 1 big US for upcoming days and ESTIMATE only these ones and then after Spike result add some USs. Will this be considered as a Scope Change? Is this a normal phenomenon?
Does this mean that during the Planning meeting the DEV team can take only one Spike and 1 big US for upcoming days and ESTIMATE only these ones and then after Spike result add some USs.
Would doing so help to ensure that the Sprint Goal is met?
However, enough work is planned during Sprint Planning for the Development Team to forecast what it believes it can do in the upcoming Sprint. Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less.
The way I understand it is that we plan enough work for the Sprint, and we decompose at least the items we plan to address in the first few days of the Sprint.
But I see many teams who prefer to decompose more than that since it gives them an opportunity to collaborate on how they plan to approach the work and gives them more confidence in achieving the Sprint goal.
Theoretically, adding members will certainly help to achieve the goal,
I personally think: if there is no new requirement, it is not a scope change
I don't think what you're describing is normal. In the context of Scrum, I would consider a large number of Spikes to be indicative of poor Product Backlog Refinement. The notion of a Spike may add value in cases where a more extensive research effort into a particular problem or to answer a question is necessary.
That said, I don't think that there's anything necessarily wrong with this approach. Although the Scrum Guide does say that Product Backlog Refinement "usually consumes no more than 10% of the capacity of the Development Team", that isn't a hard maximum or a timebox. You could craft a Sprint Goal that can be accomplished with a relatively small amount of effort and use the remaining effort toward refinement, which would be your Spike. There would be nothing preventing the Development Team from taking on additional work as the opportunity arose within the Sprint.