How do we Demonstrate Something that Results in a New API?
Or “We don't demonstrate API's, do we?”
Teams are encouraged to demonstrate everything, every User Story in the case of an Iteration (Sprint) Review and every Feature in the case of a System Demo. The idea is to generate feedback on the increment delivered and to show how we are progressing toward commitments we have made. To ensure the appropriate feedback is generated, teams are encouraged to think about demonstrating the functionality they have from an end user's or customer's perspective.
All this makes sense. However for many teams that are used to focussing on true end user functionality, showing workflows or forms as the standard part of their demonstration (for example), when they have a story that results in the establishment of an API they wonder about what they demonstrate, if anything at all.
The confusion arises from the Team's understanding of who the functionality is provided for. The Team is correct in that it is probably not the end user of their normal functionality. Rather, the end user of an API is typically some class of developer. With this understanding the feedback we want is related to how well a developer would be able to use the new API's. The Team therefore should show sample code of the use of the API so that a developer (who is, of course, invited to the demonstration) can provide feedback required.