Evaluation release mid sprint?

It is irregular to deploy releases of the latest build mid-sprint, when some of the requirements to achieve the Sprint Goal do not yet meet the Definition of Done. Remember that each sprint increment is only *potentially* releasable, so you would typically expect a release no more than once per sprint.

However, if you are releasing into a staged test environment, and are geared up to do continuous build and continuous deployment into that environment, then you should be fine. Ongoing evaluation is a best practice and you certainly don't have to wait until an end-of-sprint review for that to happen. You might want to consider including such a review in your Definition of Done for each backlog item. This should be done by the Product Owner or an authorised delegate.

On the other hand if your goal is to have "Deployed to Production" on your DoD then you would most likely be delivering to production many times per Sprint: http://blog.hinshelwood.com/the-sprint-is-a-container-for-planning-and-…

However you will need to have already implemented "feature flippers" , "TDD" and many other practices before you will be stable at that sort of delivery.

@Ian and @MrHinsh - I agree with both of you that some teams will use the Sprint as a strategic container to ship a set of PBIs as a set to achieve goal, while other teams will ship each story individually in a Continuous deploy style.

At the same time, sharing the new feature for feedback midsprint can provide fantastic benefits and that doesn't mean it's shipped to production.

I say eat up all the feedback you can get.

To clarify. This is not a release to a production environment. It would be a release to the customer's lab/test environment for them to evaluate and provide feedback on the completed PBI without waiting for the end of sprint to see it.

The sooner you can get feedback and confirm that you are building the right thing, the better. Make the feedback loop as short as possible. Cherish this customer for making that possible, both your team and the customer will benefit from this.

Regards
Fredrik

As Ian said, continuous integration and deployment makes it easy, and even if you "just" do nightly builds, you have something in the test-environment for the user.

With feedback, it is the question how you will respond to the feedback, because if you add PBI's after the feedback etc. than you get a very dysfunctional environment, where you just do scrum, to do scrum.

If you use the feedback to make PBI's for the upcoming sprints then the Customer has the chance to prepare for the Review with the nightlys and can give better feedback, and you can improve your planning process.

Regards,
Philipp

Thanks for all the great replies.

We are doing CI with regular builds and TDD so even if the build may not be feature complete for an official release, it is usually in a state good enough for the customer to evaluate the completed PBI.

As this is only our second sprint, I am hoping to focus more on having the team and PO improve our definition of done.

It would seem redundant though for the customer to attend the sprint review if the PBI's relevant to him are delivered for evaluation mid sprint.

The scrum guide doesnt address this scenario and I'm a lot more comfortable with continuing with the short feedback loops with this customer after reading the posts in this thread :)

Regarding the redundancy comment. Be mindful that
this can lead to a suboptimal use of scrum.

The sprint is meant to provide room for creative story telling. All of
the stories together tell a greater story than the sum of their parts.

What your describing is Scrum as a work management tool. That is often
a good start, but it misses out on scrum as a strategic advantage for
addressing goals in a creative way.

How did you like that wording Giovanni? :)