2

I've been asked what a team should do when the nature of the project precludes vertical slices in their deliverable stories.

The definition of 'Incremental Development' is provided here: https://www.agilealliance.org/glossary/incremental-development/

Near the top of that document is the following:

in an Agile context, this means that each successive version of the product is usable, and each builds upon the previous version by adding user-visible functionality.

I have recently had a query of the form:

What happens in an agile project when the nature of the software being built simply doesn't have a previous version to be built upon and thus cannot deliver a successive, usable version? For example, software layers in a mobile phone which have no 'phone' to be a part of yet and which most likely do not involve user input and simply provide a service to other units of functionality.

In short, how can you implement INVEST when it appears there is not enough depth in the story to do so.

(I have previously witnessed a scrum master who enforced, on a web project, full DB-to-UI work on every story - literally - and, yes, this caused a lot of friction.)

4

TL;DR

After the first couple of Sprints, a Scrum product should always be a in a potentially-releasable state. That inherently means there's always something to demonstrate at a Sprint Demo, but you may need to be creative and "think outside the box" to find it. Treat demos as first-class work products during Sprint Planning in order to make demonstrations easier and more intuitive to develop.

APIs and Middleware Aren't Magical Unicorns

What happens in an agile project when the nature of the software being built simply doesn't have a previous version to be built upon and thus cannot deliver a successive, usable version? For example, software layers in a mobile phone which have no 'phone' to be a part of yet and which most likely do not involve user input and simply provide a service to other units of functionality.

This is a common misunderstanding of what "iterative" or "incremental" mean in an agile context. It in no way means you must have a prior version of the software; it means that future versions can (and generally should) build upon the work that's gone before. Agile projects benefit greatly from emergent design, and agile frameworks optimize for that.

APIs and middleware can grow and evolve in small, testable increments in the same way as any other software can, so there's nothing orthogonal to INVEST in such systems. APIs and middleware can be versioned, modified, and extended in much the same way as more traditional software, too.

There's nothing inherent to APIs or middleware that prevents them from being kept in a potentially-releasable state or being demonstrable. Such systems should still do something, and if you can test it then you can demonstrate it.

Demonstrating Non-Graphical Whosiwhatsits

Having said all that, what seems to flummox many people is the difficulty in demonstrating new functionality in a product that doesn't lend itself easily to visual presentations. Doing so often requires a bit more creativity and agile testing experience than many shops have when they start their agile journeys. Some common solutions include:

  • Using executable tests for the demonstration.

    Cucumber is a great example of this. Seeing well-written tests (and hence behavior-describing documentation) go green is a perfectly valid demonstration for many types of software.

  • Leveraging your development or QA testing harness for demonstrations.

    Almost any brand of TDD/BDD or continuous integration will require some level of test abstraction. Mocks, stubs, fixtures, and factories often stand in for other pieces of the "real" architecture, even in integration tests. There's nothing stopping you from using such techniques to stub out the functionality of API or middleware clients in your Sprint Demos.

  • Build a "demo client."

    The point is to show your product doing something. If you can't show it in situ, you can at least create a mock-up or simulator showing how an API or middleware client would interact with your code. Demo that interaction!

  • Documentation, pie charts, and other visual aids.

    The Sprint Demo is intended to show progress, and to solicit stakeholder feedback to feed into future Sprints. While all abstractions are leaky, if you genuinely can't envision any other way to demonstrate your increment of work you can always leverage secondary artifacts. Walk people through code, commit history, living API documentation like Swagger, or other things which provide a valid view of the product's current state.

Scrum mandates that work increments be demonstrated, but isn't prescriptive about how the demonstrations need to be done. There's no mandate that a demo must require a keyboard or a graphical interface. If it's relevant to the product, skywriting or interpretive dance could be just as legitimate for the demonstration.

The framework's goal is to avoid traditional status reporting, and to give stakeholders "more show, less tell." If the team can't find a way to demonstrate the work increment, I daresay they will have a very hard time testing it, too.

Plan Demos During Planning

TDD/BDD frameworks work best when you design the tests first, rather than writing your tests post facto; it makes testing easier, and ensures the product is built to be tested ab initio. Sprint Demos are no different. During Sprint Planning, the team should factor how they plan to demo the work into their user stories and estimates on the front end rather than the back.

Sometimes planning around demonstrations may change how you slice up stories, or how you plan or estimate the work. If so, great! That means you're leveraging the framework.

Treat demos as first-class work products, not afterthoughts. When you reframe the work this way, the best way to demonstrate the work increments usually becomes self-evident.

1

tl;dr; Do your best. Try to always produce validated knowledge or usable functionality. Always look for user feedback. Don't sweat it when you don't see a good option.

The purpose of this practice was to product increments of a product. In agile we want to get rid of the idea that we know the "right" solution and we just have to code it. That's almost never the case.

This video explains the different types of process control and scrum firmly leverages empirical. (https://www.youtube.com/watch?v=S-VaiB3uPdk) In it, the goal is always to take a next small step and see how much closer that takes us to our answer. Designing a database is great if we're in defined process control because we already know for certain what all of the steps are and it's just a question of working through them. It's horrible for empirical process control because you learn little or nothing from it. You know you did work, but there is no way to tell if it's the right work.

So, if you're asking yourself what the next step is and how you'll use the next product increment to learn something about how your customer will use the product and what "done" really means for you, you're probably on the right track, even if you don't end up coding UI functionality.

  • 1
    I know my answer was accepted, but read CodeGnome's. It's better. – Daniel Aug 15 '17 at 7:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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