Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
We are doing agile software development, basically following Scrum. We are trying to do sprint reviews but finding it difficult. Our software is doing a lot of data processing and the stories often are about changing various rules around this.
What are some options for demoing the changes that occurred in the sprint when there isn't a UI or visible workflow change, but instead the change is a subtle business rule on a processing job that can take 10s of minutes or even a couple of hours?
During the sprint you create value. There is always some difference between what you had at start and end of sprint. Normally even in a way noticeable by the client. So just show the difference.
in some cases the sprint deals with discovery or internal rearrangements that may sound subtle, still you must be able to show the difference and explain the public why you think it good and what is the benefit from all the effort put in. (?In a corner case you can refer to Edison who first discovered some over thousand ways of how it is NOT possible to make a working lightbulb.)
If real processing takes long, it's okay to show a time-zipped video or just a table of figures. Or pre-collected output of results.
My own personal preference for things that do back-end work is to find the end-user change. If the data you are processing eventually winds up in a report, show the before/after differences in the report.
I'm assuming the desire for the change came from a need. What was the problem that triggered the need to do the story? Your user story 'voice form' should indicate to you how you will be able to demo the problem by acting as the user in your story (i.e. As Joanne I need to view the report without users that are in Europe).
Additionally, you can look to your test team to help you in this case. There must have been some way that the test team was able to verify that the story was Done. How did they do this? Are you able to show that process within the demo?
How do you know that a feature is working yourself? When you deploy it how do you make sure its actually working?
If you can't answer those questions then you have bigger problems than a Sprint Review. You should be able to show that in your demo.
In Scrum, during a demo, the Product Owner is review each of the stories under development and either accept them or return them to development. You need to be able to prove that a feature is working; this is normally best done with an automated test. Can you pick out the automated tests that correspond to the acceptance tests and highlight the key changes?
Your Product Owner should also be able to help; they should have a detailed understanding the product under development. They don't need understand the full implementation details but they do need to understand it well enough to be able to stand up an explain the purpose (or business value) of each feature. After all, the Product Owner is the person who asked you to implement the story in the first place!
One option I find potentially fulfilling to business (BSA's, BA's, managers, and the like) is providing a five to ten slide presentation on what was expected, and what was accomplished. And then if there is a meaningful method of displaying the results of the work done, such as a data dump, or SQL query results, and time to explain them somewhat, then I find the stakeholders to often be satisfied.
It is often difficult to provide a meaningful demo for non-programmers/non-technical staff on back-end type systems. I have tried the above a couple of times, and feel that the stakeholders were more satisfied in their response, than when I simply executed the software and showed them the results.
Granted however, this may be more work than its worth to you. You'll need to weight out the benefit and the work required to make it happen.
If your change is "back end" there is likely some ultimate User Interface where the changes manifest itself. You can show that. My team doesn't like to do that because they don't "own" that system, but at the end of the day, if that's how your customers interact with your changes, you need to be aware of that UI and know it well enough to show the finished product.
