Agile software development for a successful online platform, part 1

Agile development stands or falls on everyone involved having the same picture of the product. Four tools keep this picture up to date for us: two come at the start of every project, two accompany implementation and operations. This post is about the first two.

Step 1: structuring requirements with the story map

The user story map is a method from agile product design. It makes requirements visible and arranges them so that a shared understanding of the product emerges. We keep it in StoriesOnBoard. You have access to it throughout the project and can see where things stand at any time.

Level 1: which broad process steps do users go through?

First we break the system down into broad process steps, the activities. In the finished software they usually correspond to entire modules.

Level 2: which steps belong to each process step?

Each process step is divided into any number of sub-steps, the tasks. In the solution they usually correspond to individual functions.

Level 3: what does a step need in order to work?

The user stories hang below each step. They describe the expansion stages of a function and can be prioritised against each other: for the ‘Login’ function, signing in with a username and password is one story, signing in with a Google account a second. The most important cards are at the top of the column, the less important ones below.

Level 4: in which order is it implemented?

We bundle stories of the same priority into implementation steps, the epics. Because an epic only contains stories of the same priority, the epics can also be prioritised against each other and across projects.

This lets us develop in expansion stages rather than function by function. The difference shows early: instead of one perfectly built-out function surrounded by gaps, after a few weeks there is an end-to-end process you can test. On this first expansion stage we add special cases step by step until the effort of further optimisation outweighs the benefit.

The digital post-its remain movable: steps and stories can be added, moved or deleted at any time. Prioritisation happens through position in the map: from the important to the less important, from the simple to the specific, without losing sight of the overall picture.

This overall picture is the precondition for an architecture that can also carry later requirements. And because you have working software in front of you early on, missing or misunderstood requirements come to light while they are still cheap to change.

Step 2: visualising ideas with mockups

A mockup shows how the product will behave: a rough sketch of the controls, not a finished design. We work out the functions identified in the story map together with you, and you see a first concept within a short time.

We use Moqups for this. The tool links the screens to each other so that you can click through how things work, and comments land directly on the element concerned instead of in a separate email loop.

The mockups therefore have two jobs: they validate the requirements with you and serve the development team as a draft for the user interface.

Story map and mockup cover the concept and initial phase. Part 2 shows the two tools for planning, implementation and documentation.