No Sprint Demo Needed

Over the years I’ve done lots of work with Scrum teams and I appreciate that Sprint Demo/Review meetings can be a useful way to give stakeholders visibility of features implemented prior to pushing out a product release. Teams that find this way of working helpful typically work in larger organisations, where they don't have the capacity to make frequent software releases due to restricted access to servers or a heavy reliance on manual regression testing. However, the ceremony of Sprint Review may be propping this system up allowing teams to work in a pseudo-Agile way placating stakeholders while delaying the release of valuable software.

Nowadays I work at Unruly with XP teams who don’t hold such demos because we practice continuous deployment. Code is deployed to live environment at the earliest opportunity and often in use within our business a couple of days after planning. Where we don’t want all of our users see new features, we can put in a toggle to restrict visibility. When features are already live, the ceremony of getting together in a meeting room with stakeholders is pretty pointless. Although we do ensure that stories are signed-off by business people, often a single story owner who we’ve been working closely with during development. 

How do our wider stakeholder group (Sales, Marketing teams, etc) know what product features are currently released and find out details of how they can be used? As each story finished, developers send a release email out to internal users and organise education sessions for whoever needs to know how the new feature works. We also took some inspiration from Joe Walnes’ Testing on the Toilet and Aimy (our product manager in New York) creates newsletter-style posters for our company washrooms to illustrate and explain new features now available. We have even tried Release-Email Driven Development for a few stories, where we write the release email before starting development to ensure we've thought things through from a user perspective.

The only situation we might consider holding Scrum style demo meetings is when we are working on a totally new unlaunched product. But even then, our practice has been to make a live version available to a restricted group of internal stakeholders so they can access the product and play around with it themselves. Last year, for our Unruly Analytics product we even integrated wireframes and sketches (see pics below) into the evolving product as placeholders for screens that had not been implemented yet to provide some context for the live features.

 

 

 

Comments

[Michał Parkoła]

Hi!

In your post you seem to assume that the primary purpose of the Sprint Review is to show people what was done (hence a "demo").

From what I understand of Scrum the intended purpose of this meeting is to *get feedback* on the current state of the product (so maybe it should be called a "Product Review" instead of a "Sprint Review") and figure out together (team, PO and other stakeholders) what could be done next.

There might also be other ways to achieve that but to say "we don't need sprint reviews because we have batter ways of informing users of new features" seems to be an incomplete view.

How do you get feedback in the scenario you described?

[Growingtruffles.wordpress.com]

Interesting idea. The one part that gives me pause is the idea that the team, having just finished an intensive period of experimenting with how to meet the desired user value, has a bunch of information about what does and doesn't work. If I am the customer, I would be curious to hear about the three ways they tried to build a feature that *didn't* work, in addition to the happy path being demoed. It seems to be useful information. But maybe not. Unfortunately, I don't know. At my company, demos have had little of this component of actual collaborative interaction with the customer; they are rather one-way, perfunctory show-and-tells. After some recent reading (the Scrum guide in particular, I think), I am thinking about trying to coach my team toward more meaningful conversations there.

Am I crazy to think that such interaction actually can happen, or that it would really be all that useful? And if I am not crazy, do you handle this sort of interaction differently in your non-demo setting? Perhaps it's just mixed in to story acceptance?

[superheurist]

Nice angle - brings back good memories of a great process to see those ux artifacts: *proudly* I made those things! :)