Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
2  
unittests or file manip –  ratchet freak Jun 3 '13 at 23:48
    
@ratchetfreak: Is that a technical term, file manip? –  Robert Harvey Jun 4 '13 at 1:21
    
@RobertHarvey file manipulation, I'm thinking of command line tools and such –  ratchet freak Jun 4 '13 at 1:30
1  
@ratchetfreak: I knew what it meant. >_< –  Robert Harvey Jun 4 '13 at 2:08
    
No you didn :-D –  Esailija Jun 4 '13 at 3:59
show 1 more comment

5 Answers

up vote 8 down vote accepted

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.

share|improve this answer
    
+ Automated acceptance testing (AAT). Run the AAT on the old software and then run it on the new. Note the difference. Incorporate a scaled down representation, eg a smaller, working dataset, that illustrates the fundamental problem and solution. –  JustinC Jun 4 '13 at 6:36
add comment

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?

share|improve this answer
    
+1 for test team involvement –  Jeff Martin Jun 4 '13 at 16:44
add comment

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!

share|improve this answer
add comment

You can use powerpoint or something graphical to convey the change. For example, if there's a business rule that was added that depends on the value in a cell on a spreadsheet, you can show which cell it is and explain how it was changed.

If there's a bunch of backend changes, no UI changes, then you can just go through the list explaining it and show an overall change. If you can create a chart or graphic that highlights the differences, that may be enough. Flash some code changes or a list of changes/commits that were worked on in the sprint.

share|improve this answer
    
does someone want to comment and give a hint as to why this is a bad answer? –  omouse Jun 28 '13 at 17:17
add comment

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.

share|improve this answer
8  
-1 for slide presentations. –  Mathew Foscarini Jun 4 '13 at 0:25
    
I always put great effort against slides too. Slideware is slippery slope, we do the actual product instead. –  Balog Pal Jun 4 '13 at 10:11
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.