Allowing additions to a running sprint in Scrum

Question

If I am not wrong, Scrum groups user stories into sprints so the team focuses its resources to complete as much user stories as possible.

How flexible is the sprint planning according to Scrum ?, in theory a sprint should not allow to add new user stories to a running sprint, right ?, but what happens when an organization is doing both, implementing the product and developing the product's concept at the same time ?

For example, if business teams need to do experiments, which require the addition of new user stories to be implemented in a middle of a sprint, and such tasks should be released as soon as possible, for example if it is possible on the same day.

If the experiments do not compromise sprint planning from resources point of view, in fact there could be a "free developer" just focused on these business experiments, the integration of the experiment results could be merged into the project as tasks for the next sprint.

So, back to the question. Does Scrum consider situations like these or are there any other agile methodology that consider these and provides approaches to manage them ?

Answer 1

IT can depend on the sprint goal. Sprint goal is usually a business value and user stories could be added/removed as they are re/prioritised (as we gather more information or situation changes).

In other words, if an user story would contribute to the sprint goal, it should be assessed and prioritised, which could result in changes to the sprint backlog.

Answer 2

Please read The Scrum Guide.

Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

The framework is about leveraging agility to learn while creating and delivering a quality product.

The heart of Scrum is a Sprint, a time-box of one month or less during which a "Done", useable, and potentially releasable product Increment is created.

Sprints are a time-box in which the team can Focus on delivering value. User stories are not a requirement of the Scrum framework though they are often used and misused.

Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

Scrum absolutely supports the notion of experimentation and adjusting based on what has been discovered.

As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed.

As a framework, Scrum allows teams to self-organize in order to accomplish the goals. However, having a "free developer" working in isolation would be no less than an anti-pattern.

Answer 3

There are countless variations to SCRUM, so it is hard to make a definitive statement. For example, I have worked on SCRUMs where the rule is that developers can elect to add new tasks to the sprint, but management cannot force new items into the sprint.

For situations like this, I would look into the reasons why SCRUM does what it does. The purpose of a Sprint is to provide a manageable sized chunk of work where developers are not getting pulled off in many different directions. You want the developers focused on the sprint goal for the entire duration. If you are adding spontaneous tasks, then you risk derailing the sprint as developer have to shift gears.

If you find there is a need for a large quantity of rapid "experimental" code development, then that might, itself, be a budgetable task to be included in the sprint. Doing so would force you to meet the Done rules for tasks in a sprint, which would be considered to be a good thing. There would be a "releasable product" which needs to be factored in.

If you find that you have to modify SCRUM from any of its "vanilla" variants, then that should be a sign that your business model has some behaviors that are known to be problematic enough that the makers of SCRUM explicitly wrote those behaviors out. You should be ready for them to cause problems. It's better to find ways to work them into the paradigm, rather than inventing a new paradigm to handle them.

Disclaimer: I have worked on projects where we had exactly the situation you described. We actually built an entire development model around how to make it happen. It was actually successful, but I could see enough issues with it to recommend not following the same path.

Answer 4

Scrum does not allow making any kind of change in a sprint. As the Scrum Guide describes

During the Sprint: No changes are made that would endanger the Sprint Goal

Although it is not described on the question, chances are that the changes required in those experiments may endanger the Sprint Goal.

Then, the answer to the original question would be:

• Every change made in the sprint has to be carefully check to not endanger the sprint goal or if that happens, cancel the sprint and plan a new one.

• Look for another methodology that allows changes in a sprint.

For the second option, a way to go would be Kanban or Scrumban. Scrumban considers defining sprints as in Scrum but it allow changes as needed.