I’m an agile coach in the GDS transformation team. I help to establish and develop the agile working practices for programmes. I work with teams and individuals who are new to agile, and often the colleagues doing analysis. Analysis is the work done to turn an idea into a set of user stories for developers to work from.
Agile programmes tend to have rigour around the delivery of sprints, but the analysis is often less disciplined. It’s helpful to set a clear and constant rhythm for analysis so the right stories are written at the right time. A rhythm allows a team to feel in control of the workload and ensures there are prioritised, well-defined and estimated stories for developers.
Over the next four days I will be blogging about the activities of setting the analysis rhythm. At the end of the week you will have a collection of posts to use as a resource to support your work on large or complex agile programmes. I’ll use terminology specific to agile - the methodology we use to deliver GDS projects. If you’d like to know more about agile, here is a good introduction.
The aim of setting an analysis rhythm is to get from an idea to a continuously updated story backlog ready for development. The right amount of up-front thinking helps to provide confidence and direction, but too much may be inhibiting.
When setting an analysis rhythm I visualise the process as five linked activities
High level design
Support build and test
Getting from big thinking to building and testing could happen in a few days, or take longer. Timings will depend on what’s right for the programme. It’s beneficial to allow enough time for the analysis to be informed by up-front design, experimentation and user research.
Here’s an example of what the set up could look like
The purpose of big thinking is to agree a common understanding of scope for a chunk of work you’re delivering. Depending on how you structure your team and delivery, a chunk may be an epic, theme, high-level story or user journey. I refer to the output of this activity as the strawman.
Big thinking starts with a session around a wall, to come up with a visual representation of what you’re delivering. It’s likely to be fairly conceptual at this stage. Add to the visual representation - things to consider, what’s definitely out of scope, research to be done and questions to be answered. Assign owners to the things you’ve added.
For example when designing an online shop, the strawman for a purchase might look like this
The main focus of big thinking is to experiment what will work and iterate ideas based on feedback. Involve as much of your team as possible, especially the product manager and key technical, design and analyst roles. The designers should sketch the ideas during this activity. Sketches can be used to undertake user research and inform discussion.
Please get in touch if you have any questions about big thinking. Tomorrow I’ll explain the second activity ‘high level design’ in more detail.