How fixed is a story that is in the current sprint?
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?
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.
> 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.
Sounds like a lack of, or missing Product Backlog Refinement to me.
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.
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).
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.
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
Bottom line, Scrum is flexible between sprints but not within a sprint.
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.
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.