Is it allowed to change the stories (with the same story points)?

Be warned. Until now we failed to implement scrum so my opinions are purely theoretical. :-)

I think it depends on how hard you follow the rules. If nobody started the story yet, I think it could be possible (but should be an exceptional case) to make a kind of short planning I+II meeting to switch the story. Of course the PO should not just command to switch. The standard mechanisms should be used. The Problem is, that you disturb the team with this emergency meeting and that could have impacts on the quality of work. If it happens several times and the PO becomes used to it, the team should report it as an impediment to the srum master, so that the PO will get a shot across the bows.

I think a scrum hardliner would say that it is not possible at all and would contradict the scrum process.

I think you are wrong about your assumption that all tasks are defined in Planning II. According to my sources most of the tasks are "discovered" during the sprint.

Yes you are right that most of the tasks are "discovered" during the sprint!

> Is it allowed to change the story with another story (with the same story points)
> in the running sprint or should the sprint be canceled?

This is a very good question.

In short, it all seems to depend upon whether you take a "commitment" based view of Scrum, or one based on "forecasts". A strict commitment based view would see any change, even for a story of equivalent points, as being a breach of the Sprint and one that renders the original commitment void. It would be up to the product owner to decide whether or not to actually cancel the sprint.

A forecast based view (which is now the position taken in the Scrum Guide) allows greater flexibility in this matter. I'd therefore say that it is reasonable and fair to make such an exchange, although the development team would have a duty to explain any impact on the Sprint Goal to the product owner.

Even so, Sowatech is probably right that "a scrum hardliner would say that it is not possible at all".

Why are you wanting or needing to change stories?

It's preferable not to, because of the extra planning overhead and potential for loss of focus. But we've done it, mostly because of situations where a story became blocked and we knew it would be blocked for too long to complete it in the current sprint.

It's a negotiation, if the team is ok with it and the PO is ok with the consequences, I don't see why you wouldn't. When I first started with scrum, I would have probably argued it shouldn't be done out of principal though. As Ian says it negates the original commitment, but practically speaking if the team is ok with it then they are making a new commitment. And agile is supposed to be better able to adapt to changing requirements.

Cancelation of a sprint is done by the PO, when the sprint goal does not make sence any more.... This is most of the time not the case, when a story has to be exchanged.

Just be aware who owns the sprint backlog :) IF you own it, you can change it but the SM should make clear what's the impact of this behaviour.

There are some things that need to be defined:

"change the story" = "As a X I want Y" becomes "As a X I want Z" -> total change of purpose.

If you talk just about having discovered difficulties or new tasks in addition to what was discussed at planning & task splitting, then no, it's not a change of story. It's simply a bad task split and this discovery may or may not require an adjustment in estimation: aka the story was badly estimated. Normally this isn't grounds for stopping the sprint, only means that a lesser priority story needs to be removed.

Likewise, if the PO wants to change the purpose of a story, the original story should be removed and the new story (for all intents and purposes it is new) should be added to the Product Backlog and estimated on the next opportunity. By no means should this new story be injected in a new sprint. This is grounds for a sprint stop if the PO deems the business value of the new story to be top notch.

I don't think Sprint cancellation is the right thing to do here -- those tend to be very disruptive, rare, and only when the vast majority of the work is no longer relevant -- like when a re-org or company buyout or something really extraordinary like that happens.

Here is how I tend to coach on scope changes during the sprint:
http://www.ScrumCrazy.com/scope

As everyone said " A Scrum hardliner would say No to it" and I agree to it. However if Dev team is ready to take the new story then it should not be a problem, it should never come from PO

Also I believe that if anything new has been added/replace it would be at the last priority.

Cheers
Sanjay

Thank you for all your answers and ideas! I can agree with the @Sowatech that "Scrum Hardliner" probably never would allow to change the story, what is from specific point of view understandable. The Sprint is, on my opinion, like agreement between the team and the Product Owner for the specific time. So when I would be the Scrum Master i think i wouldn't allow do this ;-) On other side, I understand that the Sprint cancellation can imply great administration effort. The Scrum is agile methodology and when the story is estimated, the story belongs to the Sprint Goal and the team is agreed with, the story can be, in very exceptional case, exchanged.

Even going with forecast-based planning, one should figure out the reason for the swap. It should not be a decision, but a discussion between the Scrum Team with complete transparency. Under a rare situation, like business priority change, only should the story be swapped.

Another point - is that story aligned toward the Sprint Goal?

• If yes, what is the impact on the Goal? And is the new story also aligned with the Goal? And is it doable within the available time so that Sprint Goal is not at risk?
• If no, it would be good to help other members finish their WIP toward the Sprint Goal. This helps the team remain focused on the Goal.

Scrum Guide should be enough to guide you to your answer - did you read it with focus on that question in mind?

Here are some hints:

During the Sprint:

• No changes are made that would endanger the Sprint Goal;
• Quality goals do not decrease; and,
• Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

Sprint Planning:

(...) Development Team works to forecast the functionality that will be developed during the Sprint. (...)

(...) As a Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements functionality and technology. If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint. (...)

Sprint Backlog:

(...) Only the Development Team can change its Sprint Backlog during a Sprint. (...)

And last but not least, look at the pillars of Scrum, especially Inspection:

Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances. (...)

and Adaptation:

If an inspector determines that one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation.

Also remember about Scrum Values, especially Courage and Openness:

The Scrum Team members have courage to do the right thing and work on tough problems.

(...)

The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work

After considering this, doesn't it clear that despite some frames and rules to consider, people are encouraged to do the change when it seems needed? And story points do not matter here so much, it may be worth to look at them, but it shouldn't drive the decision on its own.