Once upon a time… using project stories to document your team’s progress

I wanted to experiment with a new way of cataloging the team’s progress, without overloading people with detail

At dxw, and in government, we tend to work in agile, multidisciplinary teams. This means we’re often:

As well as all this, people like to work in different ways. Some live and breathe Miro boards, some love an excel spreadsheet, and others prefer well crafted Word documents and Google slides. We all choose the methods that feel most natural, and efficient, for how we like to communicate.

So before you know it, project folders can explode with content. User research findings, technical discoveries, data maps, process maps and stakeholder notes. As a team you’re regularly exploring a few different areas (for example users, data, and technical architecture) bringing all the findings together, drawing conclusions and deciding on your next steps. This means a lot can happen in the space of a few weeks.

As someone who struggles to stay focused on wordy documents and presentations, I wanted to experiment with a new way of cataloging the team’s progress, without overloading people with detail. And also provide a way for people outside of the team to find, and use, all the good work and insights captured.

So we started to experiment with a Project Story. 

Example of a project story document that gives an overview of the work that's been done from the discovery phase into alpha.
Example project story for a project moving from discovery into alpha

What do we mean by project “story”?

A project story is a kind of ‘scrap book’ for your team’s work. It captures the most important moments that led to where the team is at any moment in time. Sam Villis’ blog post scrapbook your way to better project comms explains how this idea works in practice. 

A project story should be able to:

There are a number of reasons why I feel this approach is helpful.

  1. Something like this can become a source of truth for the project activities. It provides an opportunity to bring together different strands of work
  2. It helps teams link off to relevant reports or workspaces, whilst providing some context to how those things contributed to the project’s progress
  3. It can be used to help onboard new people to the team, particularly if they’re joining after the discovery has been completed. As well as being a valuable resource to get people up to speed, quickly, it can also act as a handover tool when a project finishes, helping clients find all the good work completed by the team
  4. It can become a useful resource for operational teams in transferring knowledge about a project. For example, when looking for case studies as part of sales activity
  5. The commitment to keeping something like this up to date, forces teams to take the time to stop, think ‘what does this mean for our project?’ discuss their ideas, and reflect on their activities in a way that can be communicated with the outside world
Overview of an MoJ project showing the design principles, inspiration taken from other services and the first set of designs
Some of the information that was included in the project story for one of our MoJ projects

How to set up your own project story

We’re still experimenting with the most efficient and effective way to manage a project story. Here’s some of what we’ve learned so far:

  1. Start it when you start your project: get commitment from the team that this is something they want to have.
  2. Nominate 1 or 2 ‘story tellers’:  a story teller should be good at synthesizing work completed by the wider team so they can form a cohesive narrative about what you’re doing and why. 
  3. Keep it high level: too much detail can be overwhelming. This is not the place to put all the details of your findings. But it is the place to share the highlights of work and link back to the original source.
  4. Make it part of the ceremonies: perhaps after show and tell when the team has already drawn its thinking together. 
  5. Be prepared to reorganise: a good project story needs a good editor. As the project progresses, it’s useful to reflect on the information in the story, and whether it still fits the overall narrative about what the team is doing and why.

What’s next for the project story?

Keep testing and learning

The project story approach is being used in a few projects, but it needs to be tested in more situations, with different team shapes and deliverables.

Improve accessibility

We know there is some work to do to improve the accessibility of an artifact like this. It could be that Miro isn’t the best tool for this work.

A new way to present?

I’d love to explore using this format for presentations and even show and tells. Moving away from pausing work to create formal presentations, and having a more organic way to share the work teams are doing.