Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

How fixed is a story that is in the current sprint?

Last post 08:28 pm July 13, 2016 by Alan Larimer
10 replies
07:12 am July 2, 2016

Hi All,

I am working as a developer in a scrum team at the customer's site. All the developers in the team, including one tester, are provided to this customer by my employer (which is a different company).
The rest of the team (business analyst, product owner, scrum master, one more tester) is employed by this customer.

During the sprints, we noticed that the stories are changed pretty often. Sometimes small textual changes (with styling implications), but also sometimes adding new acceptance criteria that cause complete new flows to be created.

The people working for the customer have the opinion that we are working in scrum and should be agile (and just do it).

My question now is: how flexible should we be?


07:26 pm July 5, 2016

Who is making the changes?

The Sprint Backlog ... belongs solely to the Development Team.

Some change is to be expected.

The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal.

The Agile values are do not dictate constant modifications.

Customer collaboration over contract negotiation.
Responding to change over following a plan.

In order to be productive, the Scrum Team and customer need to remember the rules.

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.

I'd suggest discussing it during the Sprint Retrospective. You want to provide the best possible value to the customer. You are concerned that these changes are/will be a reduction in that quality and value.


08:34 pm July 5, 2016

> My question now is: how flexible should we be?

Look at it the other way and clarify how rigorous you intend to be. The Scrum Guide is quite clear about who owns the Sprint Backlog and who has the authority to change it.

If the benefits of Scrum are expected then the rules of the framework must be observed. Implementation choices do not involve deciding which of those rules can be broken.


04:57 pm July 8, 2016

Sounds like a lack of, or missing Product Backlog Refinement to me.


06:00 pm July 9, 2016

In order to be productive, the Scrum Team and customer need to remember the rules.

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.

The first point you mention is actually the problem: usually the argument is used that the sprint goal will not be met when <additional requirements> are not added.
We have a lot of sprint goals that are something like "create the base functionality for <larger functionality>". So for me it would be acceptable to create new userstories for the new requirements.


06:05 pm July 9, 2016

Posted By Mark Troyan on 08 Jul 2016 04:57 PM
Sounds like a lack of, or missing Product Backlog Refinement to me.

You are right, but unfortunately the new requirements sometimes even find their origin in the refinement:
in the refinement we ask if it should be considered, during the refinement the answer is "no" and during the sprint it suddenly pops up as a new requirement (that is very urgent).


06:49 pm July 9, 2016

Posted By Ian Mitchell on 05 Jul 2016 08:34 PM
> My question now is: how flexible should we be?

Look at it the other way and clarify how rigorous you intend to be. The Scrum Guide is quite clear about who owns the Sprint Backlog and who has the authority to change it.

The scrum team :)
But since we also have a supplier-client relationship, that discussion is a bit hard...

If the benefits of Scrum are expected then the rules of the framework must be observed. Implementation choices do not involve deciding which of those rules can be broken.

I wonder if they care about the benefits of scrum, the focus is mainly on the short term.


01:45 pm July 10, 2016

Hi Micha,

From your post I understand that the person doing the changes is the PO. According to Scrum guidelines no modifications are allowed by anyone outside the dev team, certainly not without the team's approval. Sprint is considered as "safe space" for the team where they are not interrupted until Sprint ends. Sprint content MAY change once the dev team learns that they under- or over-estimated the work, in which case they re-negotiate with the PO during the sprint while trying not to endanger the sprint goal as was defined in the Sprint Plaaning meeting.

Hope this helps.
Michael


01:47 pm July 10, 2016

Bottom line, Scrum is flexible between sprints but not within a sprint.


01:38 pm July 11, 2016

One analogy that has worked very well for me in the past is the concept of a linked steel chain.

While you cannot bend an individual chain link (sprint), the overall chain is very flexible, and can pivot any way that the user (Product Owner) desires.


08:28 pm July 13, 2016

It seems like each Sprint's Goal is too generic. It is acceptable to "create new user stories for new requirements," they just have to go into the Product Backlog not the Sprint Backlog. Are notes created during the refinement sessions? They could be the contract to what was agreed upon when the resurface during a Sprint. "The Sprint Backlog ... belongs solely to the Development Team." The Development Team forecasts the work (it is neither assigned nor dictated by the Product Owner, Scrum Master, management, client, etc.) and forced changes to that plan are detrimental to success. I feel for you; it sounds as though you might be in a buzzword environment: "Scrum" and "Agile" are the basis for your processes but the framework and its rules are not honored. I wish you luck.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.