Iterative delivery done well, and poorly

The iterative design and development of a product or service is a concept that seems really hard for many people to grasp.

As a product manager and designated product owner within Scrum teams I’ve learned you can’t just explain it once, you can’t just structure the product backlog to be iterative and expect people to adopt the mindset. It takes a lot of coaching, persuasion and leading by example with new agile teams.

Well-executed iterations in an agile project target specific user journeys, workflows, audience groups or roles.

Rather than building half a thing that kinda works for most people you build part of a thing for specific people so that it works completely from end to end.

Well-orchestrated sprints and user stories plan to iteratively build parts of the product from a user perspective rather than an implementation model perspective.

User stories shouldn’t really care about which screens or pages features and content are implemented on.

A single user story might require modifying several pages or screens so that someone with a specific need or objective can complete a task or locate information spanning several pages and interactions.

I don’t mind developers breaking up stories into discrete actionable tasks to help them deliver it, as long as everyone is committed to delivering value to end users. It doesn’t have to be pretty but it has to be useful and help us learn whether the user story captured the requirement and whether we need to add, modify or remove something else to meet the essence of the story.

Here’s a literal application of Henrik Kniberg’s famous Not Like This, Like This comic to a screen-based software application:

Illustration of delivering value incrementally the bad way page by page versus user story centric

Hopefully it illustrates how poorly-planned incremental design and delivery may not deliver any value until several poorly-written user stories are completed. The correct way to iterate means that a single user story can be tested with the identified user, audience or role for  a specific scenario, task or information need.

By a “poor user story” I’m referring to the typical practice of using the Connextra user story format as a container to wrap around a good ol’ functional requirement, for example As a user I want to add a new record to the database.

I don’t do lorem ipsum filler text. I don’t do broken links that don’t go anywhere. If I sit a user in front of a release of an iteratively-developed product they should be able to read all the text, click on all the links and validate our design or disprove our assumptions.

This is why high-fidelity visual concepts and designs can make agile harder; they constrain exploration and learning, they support implementation model approaches rather than user-centric and they make it harder for product owners to get the team to focus on stories from the ground up when the team is working from end point designs.

This also works for service design but my specialisation is in web and mobile apps so I’ll tag one of my colleagues to explore good iterative design approaches for services.

If you enjoyed this article please share it with your friends and colleagues.

Leave a Reply

Your email address will not be published. Required fields are marked *