Sprint Review - Demo in an infra/backend environment

The key output of a Sprint Review is an adapted Product Backlog. Are invited stakeholders contributing to that activity, helping to shape the forecast for future deliveries of value, and thereby justifying their invitation?

Let's examine the word "stakeholder".  Since the team is working on things that do not benefit the end user, is there anyone that does benefit from the work?  For example, do the back-end or infrastructure changes improve the products performance or lessen it's memory requirements?  If so, then wouldn't the Operations team responsible for maintaining the production environments be a stakeholder to that?  Same could be said for the load/stress testing.  By doing the testing are you able to identify opportunities to improve the product architecture thus leading to benefits to the same Operations team?

Or could the changes being made enable the team to more quickly add new features?  In that case the Product Owner would be the stakeholder.  It could be demoed by doing a very simple exercise to change/add some kind of functionality. Do it with the new and then attempt to do it with the old.  

A demo for an internal customer that is interested in performance is not the same as a demo of a new feature to an end user.  Challenge the team to come up with ways to show their work to people that are interested or in need of the work.  Show how quickly an API responds. Show how the API has been expanded to allow a wider set of inputs.  Show how the system is now able to be load tested.  Then in a subsequent Sprint Review use that same functionality to show how it is now able to handle greater load. 

There is a reason they are doing the work.  When they are refining their stories, have them include in the Product Backlog Item a statement of the stakeholders for the work and identify a way that it can be demoed as part of the acceptance criteria. This will give them something to work towards and help define why it is important.

They find it hard to find something to demonstrate to stakeholders after every two weeks.

Why? What goals did you set for every two weeks? Do you have  a Product Backlog? If yes, is it aligned to a single product?

It's mainly back-end, infrastructure, load-stress tests etc, connecting services and such.

Is this routine work where you know what to do or is it work that is more complex i.e. more is unknown than is known?

One possibility is that it's impossible to empirically assess the value delivered by this team, in which case Scrum is unlikely to help you. Or could it be that this transaction processing is only considered its own product, because of unhelpful divisions of other processes into separately defined products? Maybe they're one product, which should be assessed as a whole.

But anyway, assuming this really should be it's own product, let's explore what demonstrate means. According to the Oxford Dictionary, one definition is:

Give a practical exhibition and explanation of (how a machine, skill, or craft works or is performed)

Another is:

Clearly show the existence or truth of (something) by giving proof or evidence.

I've learned not to waste people's time. If you want people to attend the Sprint Review, make it relevant for them. Take decisions based on their input, and don't force the event (or any part of it) to be longer than necessary. Also avoid duplicating discussions in separate siloed meetings (actually it's often a good idea to cancel those).

What are the possible reasons for investing another sprint in development of this product? I would expect there is some kind of value to be extracted by choosing what to develop in the next iteration.

I don't know a lot about transaction processing, so I'm going to use an example that I hope is more relatable: reducing the loading time of the homepage of an online shop by a few milliseconds, which might be barely noticeable in a traditional demo, and it could be impossible to get meaningful feedback from stakeholders just by showing the page loading more quickly.

But as this can have an impact on things like SEO, or sales funnels, perhaps a demonstration of the data is more useful (especially if Increments have already been released, throughout the sprint).

If an SEO expert is present, they might provide meaningful feedback based on measurements (perhaps comparing to industry standards, or guidance from search engines). Or if this speed benefit was achieved by some kind of trade-off (e.g. a fast initial load, but potentially slower experience as the user scrolls down the page, and more data is loaded), there could be people who are able to give feedback on the adapted user experience.

Perhaps impediments to further optimizing this situation have arisen, such as compliance or security decisions that have been made around cookie consent or data access. In such a case, it could be relevant to have legal, security and information officers in the Sprint Review.

Hi all,

thanks for the replies. First of all, I notice that a lot of times on this forum people want to be a coach first and mentor or teacher second. To me that's frustrating because I don't mind thinking about stuff myself, but I come here because I can't find my answers elsewhere.

So in this case, I'm looking specifically for mentoring and teaching, and specifically to the question: how do you demonstrate your important work if you don't have the stereotypical "new button in the app" to show.

I'm taking away a lot from Daniel and Simon with that regard, in that showing proof of what's made possible by the change, rather than showing the change itself, can be equally valuable and interesting to the stakeholders that are there. It also ties in nicely with our ambition of becoming more data-driven and using metrics to show the effects of our work more often.

Taking the view of the stakeholders and the way it can be demoed into account already during the refinement can be an elegant way of growing the mindset in teams.

I'm still curious, what others think about this way of reviewing the work (e.g. showing the result in numbers), because it flies in the face of some who believe that everything less than a live demo of the product is not a demo.

@Jorrit Kortink, Sometimes, asking a question is to seek clarity and also out of curiosity, and it does not neccesarily mean coaching. I do understand how you feel, I can relate to that feeling, and I'd really like to understand the situation at your end.

@Jorrit Kortink 

They find it hard to find something to demonstrate to stakeholders after every two weeks. 

Would it help to extend the Sprint length while your team is mainly working on background stuff that is hard to show? If you would go for four weeks for example, your team would do about double as much in a sprint and there may be the chance to have more the team can show.

Doing presentations on the advantages of what the team did in the background would also be a way, but it will also repeat itself and it's different to just showing in the App what you did. So Developers will have to prepare something for such reviews and may also not like doing this, as it is unproductive time. 

Hi Tim,

the thing isn't necessarily that the teams can't deliver anything of value in two weeks, but rather that they're not working on visible "foreground stuff" at all. 

Also I'd rather have more frequent moments of Inspect & Adapt to align that the team is going in the right direction, which is also why I don't view it as unproductive time. It's not building code, but it's reassuring the direction. Furthermore, if the process is highly automated, showing proof of the work done should be a matter of minutes by just running a query on your tooling.

Hi Jorrit,

Yes, I understand that. But you said team finds it hard to show anything every two weeks. Meaning there is not much to show on frontend, as they change backend. So if you go for four weeks, the chance is just higher that team finds something to show.

And please don't get me wrong. I totally support Sprint Reviews and demonstrating what has been done. With presentations I meant kind of Powerpoints to show the advantages of what has been done. The Review is not unproductive, but as we all know developers tend not to like documentation and preparing powerpoint ;)

What you could also do in the Review is explaining what was done in the background and what this is for. Can be done in a short slide or verbally. And then you could show that this background change did not change the frontend and everything is still working like it should be.

We have similar situations in our project. We have changed a module and added a new one recently. For both we needed to do some infrastructure work, before we were able to start implementing the functionalities in the following sprint. So in Review we were not able to show much on those two SBIs, so we explained and showed that the old functionality was still working.

Additionally we have an interface to exchange XML and csv files. That is always quite some work, but demontrating is rather senseless. We could show the code or the files, but no-one would be able to understand that. So in those cases we tell the shareholders which functionalities are now in the Interface and how this changes the specifications of our interface.

Your stakeholders normally don't want to see too much detail on such SBIs, they just want to know why you are doing it and if it works.