Stories at scale – part 3

This series has a part one and two

Additional artefacts

There is nothing wrong with creating additional artefacts if they help explain a particular concept or help transfer understanding around complexity. Agile does not seek to limit the options we have in communication through artefacts.

With the agile-mindset, we know from Alistair Cockburn’s work on people and communication that documentation is the worst form of communication for conveying ideas, however, that doesn’t mean that we can’t model solutions.

Whiteboard sessions are one of the best ways to convey information about stories and when the time comes to have the conversation that the card / story represents, that conversation can be a light weight model on a white board.


Lightweight modelling is a great way to share understanding and make what you are doing visible to others. There are a number of models that are considered lightweight and can be used as such, however, it is also easy for inexperienced teams to overdo these models and make them up front heavy documentation.

Always remember, the modelling is more valuable that the model itself. Do the simplest thing can possibly work and perfect the art of not doing things that are not needed.

You can find a good list of lightweight models on Scott Ambler’s website


Does that model have to then be drawn up in Visio or some other tool?

You can take a photo of the whiteboard and attach this to the story. Or you can put together the model in a tool if you choose. The idea here is that the value comes from making the model and sharing the creation process and not the model itself.

Making it look pretty might be required in some regulated environments and that is fine. In this instance, the regulatory body is one of your stakeholders and the documentation is a deliverable just as valid as code. In this case we create the documentation continuously or near the end of the process and not at the beginning.

Scott Ambler has created a great page explaining the concept of late or continuous documentation.

References to follow…

Coming next: Story examples, NFRS and constraints, and what you shouldn’t do…

Leave a Comment

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