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 ?

  • 2
    Please could you justify the -1 ? and if you believe scrum is not the best approach to solve this organization needs, suggest a different approach. Or, if the described potential solution doesn't fit scrum, suggest a way it does. Commented Feb 7, 2018 at 0:35

4 Answers 4


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.


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.

  • Thank you very much for your answer. I'll read the Scrum Guide again. Just to check I understood correctly. So, the free developer would be an anti pattern, so you wouldn't do that and in general, you would use sprint scopes and adjust sprint duration to solve the issues I define here, right ?. Commented Feb 7, 2018 at 1:23
  • 2
    @RobertoAllende "Sprints have consistent durations throughout a development effort." The Development Team forecasts the Product Backlog Items that it believes can be completed in the Sprint to achieve the Sprint Goal created by the Scrum Team. The scope is flexible, not the Sprint length. People working in isolation does not a team make. Commented Feb 7, 2018 at 2:06

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.

  • "Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum." The Scrum Guide Scrum exists only in its entirety; there are no variations: Scrum In Name Only (SINO). Commented Feb 8, 2018 at 0:30
  • 1
    @AlanLarimer It'd be nice if that was a sufficient answer to practical implementation questions, wouldn't it? I sought to answer from a practical point of view, and practically speaking, there are variants.
    – Cort Ammon
    Commented Feb 8, 2018 at 0:46

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.

  • Please, could you justify the -1 or read the question entirely, which is about an organization looking for the right process for its needs. Commented Feb 7, 2018 at 21:19
  • The opening statement is incorrect; perhaps due to your situational context or inexperience with the framework you believe it to be correct. To me, the opening question does not read as being "about an organization looking for the right process for its needs" and if it did I would consider a vote to close as off-topic (shopping list). That article contains inaccuracies regarding Scrum. Commented Feb 7, 2018 at 22:31
  • The answer has been updated with a more happy opening statement and better closing phrase. Commented Feb 7, 2018 at 22:53
  • 1
    Another factor is the time box of the sprint. Commented Feb 8, 2018 at 6:02
  • Thank you very much for your comment. You're right, I thought the time box as part of the goal but I think you're right on making the time box explicit. I'll update the answer asap. Commented Feb 8, 2018 at 22:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.