Story acceptance vs. ability to have potentially deliverable SW ready at sprint end

Question

for some time now the team, product owner and me (SM) have been busy with one task: the story acceptance and the ability to get potentially deliverable SW at the end of a sprint.

What sounds simple is - at least for us - not really easy. In the review, the Scrum process goes through the stories and accepts them or doesn't accept them. At this point the sprint activities are finished and the next sprint already greets.

So where is the problem? 2 teams (15 developers) are working on stories to bring about changes to a variety of SW modules. Continous integration is used, nightly full automated tests support quality assurance. Every team member has to merge his results at the sprint end to the development branch.

Each merge is critical, as each developer makes changes to several modules for a story, which at best are coordinated with his colleagues. The independence of stories, which may be given in terms of content, is no longer given on a code basis by the access to common modules.

If a story is not accepted, the changes must be rolled back, usually with collateral damage to other accepted stories. Also tests have to be run again to be able to say with a clear conscience that this SW is quality assured and deliverable.

What is the consequence? We have now reserved the last two days of the sprint for clean-up work: Day 1 is for merge activities and day 2 is for checking the nightly test results with fixes if necessary.

In the team this leads to displeasure (2 days missing), the product owner wonders if this can be done better - after all, Scrum is a success everywhere (?). Anyone who has read this far will wonder how a review works now. In fact, the review at the sprint end is more of a demo, the acceptance has already taken place for logistic reasons (2 days before). An acceptance doesn't take place in the review anymore.

I'm interested in how other Scrum teams deal with this everyday problem:

• a) Will the review be moved forward ?
• List item
• b) Are there approaches that defuse the problem?
• c) ...other experiences?

Answer 1

There are a number of things that might help.

First, acceptance can be a continuous process. Could more frequent checking with the PO catch problems earlier?

Has the team discussed better approaches to doing the work in retrospective that either lead to less rejections or easier rollback?

Also, are stories being rejected and rolled back because they were done wrong or because now that they are done, the PO has a better understanding of the need and requirement?

Part of why teams who really adopt scrum improve is because the constraints surface challenges that the team can improve. Very few teams successfully start delivering working software right away. It is only after multiple cycles of inspecting and improving their development process do they start to achieve this.

Finally, there are two potential antipatterns that you may be experiencing.

First, continuous integration suggests that everything is built and integrated quickly. I wouldn't expect any team member to go more than a few hours at most without checking in and merging code. What you describe sounds more like merge avoidance.

Second, your 2-day freeze creates a buffer. Buffers are often used to avoid facing challenges. They can be helpful as a bridging strategy, but should always be temporary.

Answer 2

Adding to Daniel's excellent answer...

A good way to de-risk merging is to merge frequently in the other direction.

For example, the team could use continuous integration to automatically pull code from the head into their feature branch. That way if anyone has introduced code to the head that breaks the branch they will know about it immediately.

The benefits of this approach include:

• Code conflicts are found very close to when the code is committed, so it tends to be easier to fix them
• The code in the branches is typically in a reasonably good state
• The code in the head is stable almost all of the time (because you are merging in already merged code)
• The continuous merging forces the teams to communicate frequently

If you are using a distributed version control system like Git you can even go a step further by regularly merging from head in to individual's repos.

Answer 3

All the other answers contained helpful advices, I have to add some more:

Continous integration is used, nightly full automated tests support quality assurance. Every team member has to merge his results at the sprint end to the development branch.

This is not continuous integration. In teams I've been working with, "Sprint Branches" turned out to be helpful. The whole team commits then to that branch during the sprint.

If best effort stories are taken into the sprint near the end, and it is totally unsure, if that story can be finished on time, sometimes we create a feature branch for that story, but only very rarely! At the end of one sprint - or the beginning of the next one - the sprint branch is then merged into the develop branch, totally no hassle, since it is only one merge where most of the time only one of the two branches has changed.

Also, are stories being rejected and rolled back because they were done wrong or because now that they are done, the PO has a better understanding of the need and requirement?

No, stories are not rejected because of misunderstood requirements or the PO changing his mind. First of all, you should involve the PO early in the development process, show him features while they are growing, ask him for feedback during the sprint, not just at the end. Especially if the devs are unsure they (!) should ask the PO directly.

And if PO finds out that he wants to change a feature after its story was implemented, thats good. That is why you develop agile - to get early customer feedback. But the story has to be accepted nevertheless - PO can create a new story with the changed requirements. (I have to admit, if the PO changes his mind too often, it can get a bit frustrating, especially if you have to remove things you were proud of)

If a story is not accepted, the changes must be rolled back,

For this, your devs could implement feature toggles that can be configured after deployment/installation. They would simply hide features that were not accepted while keeping the parts of the code to fix the things that lead to the denial of acceptance. I never worked with feature toggles, only know them from theory.

In my experience, if the PO did not accept a feature, it was simply fixed during the next sprint. The potentially shippable product was not put productive every sprint, but POs planned some sprints in advance and before a "go live", some time was dedicated to polishing the product. (Maybe with things that were not worth a whole user story like "put this box three pixels to the left".)

We have now reserved the last two days of the sprint for clean-up work:

Are you sure, the length of the sprints is working good for you? If you need two days for cleanup (besides that maybe necessary cleanup is not a good sign at all), maybe shorter sprints would suit your situation better? You also "force" your PO to give you feedback earlier.

Additionally I would suggest:

• Adapt Scrum to what your teams need - but don't call it "Scrum" then any more ;-)
• You as Scrum Master have to defend the team against misunderstandings - either by arguing with the PO or better by helping the PO to write stories that are clear for both sides.
• Find solutions to the occurring problems with the teams in the form of retrospectives! Don't push them to any suggestions from outside - they have to decide for themselves. But please don't let them change too much at once - later it will be hard to distinguish the changes that were helpful from the hindering ones.

Answer 4

One of the things Scrum does effectively is surface problems, and I believe that's what is going on here:

Every team member has to merge his results at the sprint end to the development branch.

This isn't a sprint or scrum problem: it's a repository workflow problem. Having developers work on separate branches for days at a time and not merging til they're done sounds like a recipe for merge conflicts no matter what else you're doing.

I agree with Barnaby's practical advice on how to address this underlying problem.

Good luck!