How do you write good Agile user stories if elements are missing?

In the real world you’ll often find yourself working on projects where some of the elements are to be delivered later. These elements might include a third-party API, some bit of infrastructure or brand delivery. These missing pieces make it impossible to write user stories which take a genuine slice through the system and which will produce a feature that is releasable.

Obviously this is less than ideal but sometimes it’s unavoidable. How should we deal with it?

The wrong way

Often a team will deal with external dependencies by writing user stories based on what it’s possible to do outside of the horizontals with missing elements. In other words, the team will avoid tackling any part of the project that is impacted by the elements to be delivered later.

For example, let’s say we were missing brand assets from an external design agency. It would be tempting to write stories to encapsulate the back-end work only, leaving front-end work for a later sprint when the assets are available.

This back-to-front approach has obvious drawbacks: it’s not value-focused, it doesn’t produce user stories that are end-to-end testable (or that fail to meet other criteria of the INVEST acronym I’ve talked about before) and it almost certainly won’t adhere to the product vision.

Essentially it shuts down discussions of what’s possible early on in the process and so inevitably results in a loss of value.

The right way

The right way to deal a situation like this, in my opinion, is to stick to the principles of what makes a good user story.

Remembering that each story needs to be Independent, Negotiable, Valuable, Estimable, Small and Testable, we can always find a way to take an end-to-end (vertical) slice through a feature.

Sticking with the example of a missing brand identity, we can’t write a story that will produce a releasable feature. But in my previous post I outlined a way of slicing stories so that different levels of richness could be represented by successive stories.

Using this technique it’s easy to envisage an initial story which would (taking the missing brand assets as an example again) produce a functional, testable framework to which the brand identity could be applied later.

It’s important to note that this approach might also necessitate easing back on some of the acceptance criteria. For example, the absence of branding would mean doing away with performance acceptance criteria.

The benefit to this approach is that you can still work towards your original vision – which not only means greater coherence and cohesion among the team but also inevitably means that your stories are delivering more value than they otherwise would.

Because you’re taking vertical slices you also end up with demo-able features so that you can incorporate feedback into future iterations.

In conclusion

External dependencies of course lead to inefficiencies but sometimes there’s no other way to get things done. By sticking to the principles of a good user story, and by taking end-to-end slices through the features being built, you can maintain a value focused approach.

This might mean sacrificing some richness and some acceptance criteria in initial iterations but it will also mean that the team continues working towards the original vision, rather than just aiming to work on the elements of the product they can get release-ready. It also means you’ll be maximising value within the given constraints.