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.
Aim
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.
Activities
When setting an analysis rhythm I visualise the process as five linked activities
-
Big thinking
-
High level design
-
Detailed design
-
Support build and test
-
Support iteration
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
Big thinking
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.
2 comments
Comment by Mary Martin posted on
Start with the big idea - makes perfect sense. Interested to hear how you might tie this into policy / strategy work ( which may have informed the business case) to get early involvement from these stakeholders and buy in to the approach at the initial stages. Useful participants in understanding any initial constraints too.
Comment by Davina Sirisena posted on
Hi Mary,
On a larger government project or programme you will ideally have a policy person as a full time member of the team. They would sit with you and hence you’ll be able to easily pull them into these sessions as needed.
This is particularly helpful when you are implementing a service for a new policy. Firstly this helps ensure that the policy is well understood and correctly implemented. Secondly, if your evolving understanding of your user needs indicates that the policy could be improved, it gives you a route to challenge it. The need for iteration applies to the policy as much as it does to other aspects of your service.
More broadly speaking there is of course a need to include stakeholders outside of your immediate team in your thinking. I favour doing this via something I call the ‘intelligent challenge’ which I’ll be talking about that in Part 2 of my blog later today.