Continuous Integration / Environments / Builds etc...

Which of the approaches you describe would allow a genuine Sprint to be conducted, so an increment delivers something of value to the Product Owner, no matter how small?

@Ian, thanks for your reply. Tough question. I sense you're trying to direct me down the second path. True, there is no real value for the Product Owner in a perfectly operating CI system, and provisioned environments that have nothing there. So are you suggesting that the first PBI be something like

View home page

And the team adds tasks to do with setting up builds and deployment scripts/environments

There is a very real tension though between doing the minimal that could possibly work, and deliver value, and doing things looking at the long term health of the project. E.g. I could easily manually upload a simple html page to an S3 bucket, manually add a DNS entry into Route 53, and BAM! PBI done, value delivered. But we know that following this pattern will be wasteful for the development team long term.

What's the solution?

I could easily manually upload a simple html page to an S3 bucket, manually add a DNS entry into Route 53, and BAM! PBI done, value delivered.

I think you've drawn a useful distinction here between the quality of ways of achieving the PBI.

If it's an important quality of the product that it can be deployed via CI, perhaps that should be part of the definition of "Done".

The logical conclusion here might be that you would only build the necessary parts of the CI system to deploy the home page, then as you add extra features, you can build more of the CI system, as required, to meet the definition of "Done".

Each increment must provide some valuable functionality, no matter how small. If most of a Sprint is spent on establishing technical foundations, then it is advisable to supply just enough MVP functionality to validate the foundation created.

This might be a transactional user story or scenario which proves that essential architectural layers are working. Sometimes this is referred to as a tracer bullet or a stovepipe prototype.

If you only delivered a CI/CD set up in your first Sprint and no features, what feedback would you be able to get from your stakeholders at the Sprint Review?

I feel like Simon got it right around the DoD and building part of the CI along with at least one feature.  In my opinion, with some of the CI/CD tools like Bamboo, and if your team is using the Cloud (i.e AWS or Cloud Foundry) to deploy your code, many Dev teams can accomplish an initial set up and also deliver an increment of functionality within the same Sprint  I get it though, if your team is not using some of these newer tools it could be a chore.

I would lean towards asking the team if some of the CI work could be part of tasks of the first backlog item that is high priority for your Product Owner.  What if your team started with only one environment such as test, and looked to revise the DoD during each Retrospective, and build out the other environments each Sprint?  All while delivering business value?

It is important to keep your stakeholders happy with progress in your Sprint Demos, and more importantly to get their feedback about the delivered feature(s), and to talk about what the team is learning about CI/CD, and how this will help the team go faster and build a better quality product by catching issues earlier with these new XP practices.

All the best!

@Ian - I appreciate the powerful questions you raise, and really like the tracer bullet analogy that cuts through a thin, vertically sliced feature.

All the best!