How can user stories meet INVEST criteria in design-led development?

Question

How should our team handle agile development when the development is pretty much steered by the final product designs, which were done in advance? In other words, how can we break down requirements into small INVEST user stories when the only artifacts you have are the FINAL (gold plated) designs?

For example - the designer designs a telephone with many buttons/features (call waiting, call block, etc). The business (for obvious reasons) wants to delivery value, quickly. So, my understanding suggests we might:

1. first build a phone with no buttons that can RECEIVE calls,
2. then build in some buttons purely for dialling,
3. then build in a "hang up" button
4. then build a loudspeaker

etc...

However, we have no designs for the phone with X buttons at Stage 2. It seems like potentially more work/headache for a developer to build something that we know will need to be done (from a front-end point of view).

Solutions:

1. produce wireframes to support the incremental building of features (rather than JUST the end product designs)
2. let the dev run with it - barebones, no design

Hope I've explained this sufficiently.

Answer 1

The challenge of reducing a project's full monty to an Minimum Viable Product (MVP) is one of the larger hurdles in moving from Waterfall to Agile project, or starting any project in Agile. In particular when Product Owners create all sorts of interdependencies between various features, arguing that they need to all be delivered in Phase 1.

I would argue that the key step to manage is carving out a MVP from the overall project. In your telephone example I would go even further and say that RECEIVE CALLS is almost nice-to-have. The MVP IMHO could be a telephone that can handle an ACTIVE CALL, without specifying DIAL NUMBER or RECEIVE.

A suggested recipe:

1. Scope out features
2. Create a process mindmap
3. Carve out an MVP, as in the graph above
4. Follow Lean UX principles using low-fidelity artefacts (mock-ups, wireframes) until your certainty of the key features improves.
5. Get stakeholder input, review, refine, reprioritise.

If the PO has trouble prioritising, you can consider moving from a feature list to a behavioural inventory of Jobs That Need to Get Done. Prioritise jobs by a value dimension (amount of time needed, associated cost, manual steps involved) and then it often becomes more apparent as to what needs to be done in which order and which sprint.

As your process is Designer-led, he/she needs to be 1-2 weeks ahead of the Scrum team implementing the backlog in order to get User Stories into the backlog for refinement, sizing/estimation and then prioritisation.

Answer 2

TL;DR

The goal of story decompostion isn't reducto ad absurdum. The goal is to chunk up work into increments that can be done within a defined time-box.

By limiting the cone of uncertainty on the larger project and focusing on short-term deliverables, the business increases predictability at the potential cost of additional work as designs and implementations are refined (or even redefined) over time. Agile frameworks optimize for tight feedback loops and predictable cadence, rather than to avoid the possibilities of rework or redesign.

Think Functions, Not Widgets

It's unclear from your post whether you're really building a phone as your deliverable, or if you're just using it as an example. If the latter, it might help to rethink how you view your intermediate deliverables.

In your example, you assume that a phone is all about the user interface, e.g. the buttons. But what if you think about functions instead? For example:

1. You might build a phone without a case, with just a breadboard and an exposed speaker/mic.
2. You build a functioning keypad.
3. You refactor until you can wire the keypad into the phone.
4. You build a functioning ringer.
5. You refactor until the the ringer can be incorporated into the prototype.
6. You design a case.
7. You refactor the prototype to fit into the case.

Right-Sizing the Granularity of Increments

Think in terms of potentially-shippable increments. The point isn't to reduce the user stories to the point of absurdity; the goal is to build increments of your product in chunks that make sense for your project, and to let the self-organizing team figure out the tasks needed to do so.

Using your example, having one user story per key on the keypad would be ridiculous. If the team thinks "build a keypad prototype" is sufficiently granular to deliver within a single iteration, do that!

On the other hand, perhaps you work at a company that builds modern office-class SIP phones. In that case, a less granular story like "build a protoype phone to fit this artist's rendering of a new case" might be something that can be done within a single iteration using readily-available parts and know-how. In that event, there's no benefit to decomposing the story any further; just stand back and let your experienced, cross-functional team get it done!

Answer 3

Supplementing the MVP approach, one exercise to help identify and avoid rework that can be hiding among the must-/want-to-/nice-to-haves is to map out the UX and identify potential knock-on effects (preferably as a team). I tend to do this by representing features as individual columns, each with vertical bands of "done-ness" (lowest band might be wireframe, mid might be prototype, top might be release-quality). I start with highest priority columns on the far left side, headed right as priority drops. As you reach each feature column, you can discuss how vertical (done) to take it before it becomes too expensive because of the effect on other features nearby. In your example, if you were to develop each column or feature to completion ("gold"), one at a time, then each new feature would probably push the others back down to the wireframe band, and require building each one back up towards a release state. Sounds expensive! :)