Skip to main content

Evaluation release mid sprint?

Last post 09:56 pm February 14, 2013 by Ryan Cromwell
8 replies
02:27 pm February 13, 2013

Hi everyone. I'm a newbie PSM and we are starting our second sprint.

One of the customers (highly technical person) has requested that he be allowed to review a build of the software mid sprint when we finish a particular story so that he can give feedback immediately without waiting until the end of the sprint.

We have a good working relationship with him and have done this in the past before we adopted scrum.

What are your experiences with mid sprint releases?

03:00 pm February 13, 2013

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.

03:16 pm February 13, 2013

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:…

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.

03:45 pm February 13, 2013

@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.

05:45 pm February 13, 2013

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.

01:46 am February 14, 2013

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.


04:33 am February 14, 2013

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.


12:12 pm February 14, 2013

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 :)

09:56 pm February 14, 2013

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? :)

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

Please note that the first and last name from your 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. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, 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 may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.