Being user-centred is a thread that runs through all of our work here at Hippo. We spend a lot of time researching and championing user needs to build better products and services. We employ user stories to contextualise and articulate the needs of our users to shape development and design. Yet why is this format rarely used, if at all, to contextualise and articulate the needs of the team?
When working with new teams across various projects in a company, it can be hard to get to grips with how a team operates on a day-to-day basis, what challenges and pressures they face, what they do well and how they might need to improve and develop. This is especially important to get to grips with when you are assessing the agile maturity of a team.
Faced with a new team and a project with looming deadlines, I needed to quickly and easily understand team needs and their journey through a project and take a health/temperature check of the team during this process. Adopting a user-centred mindset, I began to stitch together different user research tools to try and understand the teams better.
I began to ask the question, what is their story?
What is a team story?
A team story is a tool that can be used in an agile environment to capture a description of a team’s experience through a project from inception to delivery. It provides high-level insight into the team’s health throughout a project cycle, any blockers or pain points they hit and what opportunities there are for growth and development.
This isn’t a tool for micromanaging and monitoring progress. It is a tool to measure health and agility. More importantly, this story is a narrative that the team control and owns.
How do I get to the team story?
The quick answer is to empower the team to tell it.
As with any user research, we had to get out there and speak to people who were using a service. Or, in this case, understand a team and their experience of the current process for delivery. My colleague Elisse Jones and I developed this idea in a bid to understand new teams so we could better assess what, if any, help was needed. This tool/technique is best used in a workshop setting where the full team gets involved in the process. Where they are in charge of the narrative.
How do I use this framework?
As we anticipated lots of healthy discussion from the teams, we kept the workshop quick, simple and engaging to enable us to keep momentum and engagement high (timeboxing it to 1hr).
Using a template, we mapped out (in post-its) the y-axis and invited the team to discuss what their high-level process was (capping it to 8 stages max). The teams we have been working with can have quite complex processes to deliver, so keeping it at a high level was important in order to keep the focus, cover the wider experience of the team, and ensure the final artefact produced was manageable. It also kept things simple and easy to understand therefore increasing the accessibility of the information produced. After all, there is no point in producing something that you, or a colleague that was away that day etc, can’t understand in a month’s time. Keep it simple. Keep it accessible.
Once the stages of a project cycle were defined and agreed upon by the team, we then started to work down each row across the project cycle. Colour coding is important here to not just make it easier to document afterwards but reduce the cognitive load for those in the workshop.
Each row had 5 minutes of silently writing down their responses on post-its. The team members were then individually invited to come up to the board and stick their post-it notes onto the story and talk a little bit about their experience. As you move down the board, a fuller picture begins to form, and hot spots will start to appear on the board, giving you a richer picture of the overall narrative and the team’s role within that.
Once you reached and completed the pain point row, we paused. As the team we were working with was large, busy with BAU and co-located, we used a small cross-section of people functioning within different roles in order to produce a diverse picture. However, although this gave us a great starting point, it wouldn’t give us enough quantitative and qualitative data for the team story to be accurate or meaningful.
The next step was to digitally capture the board and push it out to the wider team for feedback and further input. Once we did this, the engagement was overwhelming, giving us more than enough to build a really strong narrative around the team’s story.
From this, we were able to identify opportunities for some agile coaching and major blockers caused by the IT infrastructure. The team’s health overall was great, but we could see that at certain phases of the project, stress levels were at a peak and resources were overstretched. This insight enabled us to make recommendations on where flexible resourcing could be used more efficiently to ensure those stretched periods to support the team when they most needed it. It also meant that at slower stages of the project cycle, those team members could work flexibly and help out others.
This process still needs tweaking, but the overall outcome was rewarding. So, give it a try. I’d love to hear people’s comments about how they found creating a team story and what impact that had on delivery and team growth.
