Skip to main content

Scrum and Innovative product development.

Last post 02:45 pm October 8, 2015 by Ian Mitchell
3 replies
05:55 am October 8, 2015


As a Scrum Master thus far, my experience is mostly around adding new features to existing products.

I am now a Scrum Master for a small team dedicated to building completely new Innovative products. Our current product has a clear (although expanding) vision. We know, at least minimally, what the product should do.

The question is this. Since the product's UX is changing constantly, insofar as the team produces something 'potentially shippable' (and this for me is an interesting concept as anything potentially shippable would be for external clients and should be perfect) and in Sprint Reviews (or external user testing) the feedback can lead to a massive change in UX design - how much testing should I be coaching the team to do?

It is difficult to test. As we are building mostly happy paths, the testers are uncomfortable with little or no error handling. Sometimes they are told validation will be added later. Should this really be built in from the start? This would make functional slicing of the product extremely difficult. To produce something potentially releasable in a single sprint would probably be impossible.

The engineers question the point of covering everything with tests (or adding validation etc), since the whole thing is likely to change next sprint anyway.

How should I approach this? It seems wrong to build an admittedly ever changing product without tests, but the argument is generally 'until it actually goes out, there is not much point". For me, this will lead to a big testing phase as soon as the stakeholders say "It's great - ship it!".

Any advice gratefully received!

11:22 am October 8, 2015

There are different layers to testing. While the UX may indeed change, the underlying logic should remain stable, and it is this layer that you should be developing test coverage around.

Quality should never be negotiable in Scrum. It needs to be built in to every work product from the start. I agree with your testers that a lack of exception processing is a big concern.

Keep in mind that potentially releasable does not mean that it has to be released. In theory, it can be used, but it does not need to be in a final "perfect" state.

11:57 am October 8, 2015

It is the front end that I feel most uncomfortable about. The back end is covered by automated tests, which is good.

The problem is on the manual front end testing, and to some degree, the automated tests surrounding the front end. In fact, we no longer have a full time tester on the team, and trying to justify having even some testing resource for a front end that could change next sprint is difficult.

I agree about the 'potentially releasable' definition. In my previous role, we wrote software for the internal business, and anything that isn't strictly customer facing could always be potentially releasable (with the right training, discussions and managed expectation). When your customers are external 'potentially releasable' is not really potentially releasable at all. If it isn't perfect, it isn't potentially releasable. Your brand will be judged by it.

02:45 pm October 8, 2015

> When your customers are external 'potentially
> releasable' is not really potentially releasable
> at all. If it isn't perfect, it isn't potentially
> releasable. Your brand will be judged by it.

If you defer release until perfection, you will have a large batch of work that remains unvalidated in market conditions. It may not be as perfect as supposed. The product will represent a huge leap of faith. Moreover, the work-in-hand will have been subject to depreciation over that period, and any possible return on investment will have been deferred.

There is an art and a science to crafting a "Minimum Viable Product" which facilitates release early and often, but without putting established assets...such as a risk. The skill lies in framing an MVP as a hypothesis to be tested before a more substantial commitment is made. For example, prototypes may be evaluated in a sandboxed environment using selected customer cohorts, or very small changes may be tested on randomly selected users.

This is the Lean Startup approach. It is applicable to Scrum at scale, though it requires a Product Owner with an entrepreneurial view for it to work.

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.