If you're like me and love problem-solving, it's tempting to jump straight into finding solutions. But often, we must slow down and, before finding solutions, find problems.
Problem-finding leads us to solve the correct problems. As I began my new role, I asked the creative director if I could spend the first few weeks conducting research to learn about the environment, people and pain points.
I've always been relatively intuitive, quickly perceiving what was happening in the immediate and broader contexts. Over the past ten years, though, I've really grown to love research. I have both learner and analytical in my top 10 StrengthsFinder strengths, and getting to do user research leverages these strengths.
This post if part of a Creative Scrum series where we explore the how to apply agile for creative teams.
Having spent the previous five years designing experiences for high school and college students, I had developed a tight user focus.
Our team had implemented significant user-focused change powered by surveys, interviews, focus groups, marketing research and user testing. Those experiences were products, and we had a clear set of users.
When designing organizational systems, the question, "who is the user?" can become more complicated than it usually is with products. In the system, there are a lot of users.
We had the creatives, which could easily segment into videographers and graphic designers, each with their own pain points and goals. We had the clients who requested work, the stakeholders they represented, and higher-level leaders who wanted to know what was happening. There were also partnering teams, like marketing and communication, who we collaborated with but were outside the creative department.
When we narrow our focus to one set of people, we risk truncating the “customer base.”
I included all of these users in my research, primarily focusing on the creatives and clients. I chose those two because they had the most interactions and were the closest to where value was being created.
Partnering teams came in third for this same reason of being a critical part of value creation. Stakeholders and leaders rounded things out. They are an essential audience but are less complex and frequent in their interactions with the system I was evaluating.
Interviews were the primary method for my research. I chose interviews for two reasons:
I began with a few more extended unscripted interviews with the creative director and previous production lead.
I wanted to understand the goals and how things currently worked and felt. This process helped me get oriented and identify goals for my research and the future system.
A key quote I got from the creative director was, "I wanted clients to tell others, 'C1M (the creative department) is a joy to work with.'" I also saw how the current system exasperated our production team and creatives.
Trust and empathy will pay off in the short and long term.
These insights helped me frame who I talked to and what questions I asked.
Moving to more structured interviews, I created two questionnaires, one for internal to C1M and one for those external. I kept the questions open-ended while still ensuring I got a good feel for their user journeys.
In our world of digital distraction, pen and paper cultivate a sense of being more present in the conversation than where there is a screen between you.
I mostly followed the order on the questionnaire but also flexed as the conversations naturally progressed. You can see the questions I asked.
I could usually get an interview done in about 30 minutes, but I often ended up using an hour because of the value of building relationships. I printed out the worksheets and took notes by hand.
I find that in our world of digital distraction, pen and paper cultivate a sense of being more present in the conversation than where there is a screen between you. Oddly enough, this still seems true even when many of my interviews with through a video call. Handwritten notes also let me capture observations in a non-linear way that is sometimes difficult with a keyboard.
After a batch of interviews, I would take a few and process them using the following steps:
I used a tool called Miro for this. It's a digital whiteboard and probably my favorite collaborative tool for teams, whether distributed or co-located.
The groupings of the sticky notes evolved a bit throughout the process as new trends emerged from the data. I tagged each sticky with a label for which category of user (creative, studio-lead, client, partner...). This gave context to the comment with enough anonymity that I could transparently share the board with anyone.
Problem-finding leads us to solve the correct problems
As with any time you collect feedback, there were hard things for people to read. I found my role often was to give encouragement, context and hope to those reading through all the notes. In the end, the creative department’s leadership team identified some key areas to improve upon.
By using user stories, you can say goodbye to the wasted time of working on the wrong thing.
People don’t operate in isolation. They are part of a more extensive system. And systems are usually more complex than we initially perceive. I want to reiterate some important considerations to make if you are designing multi-team systems:
It’s popular when designing products to relentlessly focus on the customer. There’s a good reason for this. They are who you are trying to solve problems for and deliver value to.
Systems, however, are composed of people and interactions. When we narrow our focus to one set of people, we risk truncating the “customer base.”
In the system, there are a lot of users
When designing creative Scrum, I had to take into consideration the clients, the stakeholders, the partners, the creative teams, and the leadership. Each group wasn’t just a key customer. If I ignored any of them, I wouldn’t lose a portion of the system; I’d lose the whole thing.
This is a lesson I learned the hard way from years of designing in-person experiences and taking a nearly exclusive focus on the guests while marginalizing the hosts.
I’m trying to stay off the soapbox, but I really don’t like the term user. It's a very transactional and flat representation of a person.
You may be an outside consultant, but you'll likely be around for a while. Make a long-term investment in building relationships as you go through the process. Trust and empathy will pay off in the short and long term.
For a deeper dive check out these additional phases of my creative scrum journey.
The scrum team is made up of the product owner, scrum master and development team. They each play important roles.
Learn more about how a scrum team works together. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
Project managers and scrum masters differ in where they focus and what they emphasize.
The project manager is focused first on the work. Does the project have everything it needs to get done? The scrum master is focused first on the people. Are they the best team they can be to get projects done?
Continue learning about the relationship between a scrum master and a project manager. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
This combo is very doable, but it depends on the person. Some people are great team contributors but are not good scrum masters.
Often, people suggest the type A personality to be the Scrum Master because they seem like the typical leader type. Unfortunately, what usually happens here is that person begins to act like the team's boss, which is not the role of the scrum masters.
Learn more about the roles of a scrum team. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
With less than three, you don’t get much of the benefit of collaboration or shared momentum. More than nine, and the logistics of coordination start to eat away at the benefits of coordination.
Learn more about how a scrum team works together. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
Scrum is founded on three essential pillars, and each leads the team to ask a critical question.
Learn how to apply the three pillars of Scrum and then explore the most common terms in a Scrum glossary.
There are five values critical to the practice of Scrum: commitment, courage, focus, openness, and respect.
Learn how to align Scrum values with your organization and then explore the most common terms in a Scrum glossary.
The sprint goal encapsulates the product owner’s vision into a concrete statement for the development team to measure the sprint against. The sprint goal provides a theme for the sprint’s work helping the team see how all the parts come together.
Learn more about the role of the sprint goal in scrum and explore the essential Scrum glossary.
There are actually two backlogs, the product backlog and the sprint backlog. They each contain the definitive list of work to be done. The product owner keeps the backlog ordered by priority.
Learn to use the backlog in Scrum and check out the sprint backlog vs product backlog in Scrum.
The product backlog prioritizes the features needed in the product. It is a singular visible source of requirements for the product.
The sprint backlog represents the work to do in a given sprint. It is a definitive list of all the scrum team is being asked to produce for the sprint.
Learn more about the sprint backlog vs product backlog in Scrum.
Each item in the backlog represents precise work and value to deliver. Often these PBIs are written using both user stories and acceptance criteria. The PBIs are what gets refined during the backlog refinement session, and if one is too large, it may be broken down into smaller PBIs.
Learn more about how backlogs are used in scrum, the sprint backlog vs product backlog in Scrum and explore the essential Scrum glossary.
The Scrum sprint backlog is a prioritized list of items from the product backlog that the development team plans to complete during the upcoming sprint.
It is a plan for the Sprint and is created during the Sprint Planning meeting where the Development Team decides on how to build the functionality that meets the Sprint Goal. The Sprint Backlog typically includes user stories, bugs, technical work, and other items that the development team needs to work on during the sprint. Each item in the Sprint Backlog has a clear definition of done, so the team knows when the item is considered complete.
The Development Team is responsible for creating and updating their Sprint Backlog throughout the Sprint, making sure they are on track to meet the Sprint Goal. The Sprint Backlog is a working document that helps the Development Team visualize their progress and make any necessary adjustments to their plan as they go along. The Sprint Backlog is also transparent, allowing stakeholders to see what work is being done during the Sprint.
Learn more about the backlogs of Scrum.
In Scrum, the product backlog is a prioritized list of features, bugs, technical work, and other product-related items that need to be addressed by the development team.
It serves as a single source of truth for what needs to be done on the product.
The items in the product backlog are ordered based on their importance to the product owner and the value they bring to the end-user. As the project progresses, the product backlog is constantly updated to reflect new priorities, changes in requirements, and feedback from stakeholders.
The product backlog is a living document that evolves throughout the project's lifecycle. It provides transparency and enables collaboration among all members of the Scrum team.
Learn more about the backlogs in Scrum.
They keep the team focused on the value they create for the end-user and are written using the following format:
See examples of user stories to learn to write your own and explore the essential Scrum glossary.
Acceptance criteria is written using the following structure:
Learn more about how acceptance criteria is used in Scrum and explore the essential Scrum glossary.
A user story focuses on the identity, goals and motivations of the user you’re designing for. It emphasizes the why of the new functionality.
Acceptance Criteria focuses on the action taken by the user to meet their goal. It highlights the what of the new functionality.
See more acceptance criteria examples and learn to write acceptance criteria or learn other essential scrum terms.
Acceptance criteria is structured using the template
Here are 3 examples:
Checkout process functionality
Advertising campaign
Marketing campaign (Did you know you could use Scrum for marketing)
See more acceptance criteria examples and learn to write how to create your own or learn other essential scrum terms.
They aren’t absolute measurements like hours or days but measure the amount of work a PBI takes relative to other PBIs. Typical measurements include using Fibonacci numbers or t-shirt sizes.
Learn to use story points and explore the essential Scrum glossary.
They aren’t absolute measurements like hours or days but measure the amount of work a PBI takes relative to other PBIs. Typical measurements include using Fibonacci numbers or t-shirt sizes.
Learn to use story points and explore the essential Scrum glossary.
In Scrum, you are not measuring work in absolute terms like hours spent or lines of code to be written. Two reasons for this:
The problem with absolute sizing using hours is you begin to measure the people, not the work. Relative sizing measures the new work against past work shared by the whole team. Instead, the work is sized relative to past work already completed. So when looking at a new user story, the team asks, “Is this user story A most similar to this past user story B or this past user story C?”
Learn other essential Scrum terms.
The Fibonacci sequence is the go-to solution for many Scrum teams because it allows for relative sizing while still being a numeric measurement. It has two key advantages:
Non-numeric options are still possible, and one of the most popular is using t-shirt sizing, like small, medium and large. Lean more about using story points or learn other essential Scrum terms.
This measurement allows the product owner to forecast when future features will be ready. It is calculated by averaging how many points the team has complete over the past few sprints.
Learn to forecast in Scrum using velocity and explore the essential Scrum glossary.
Acceptance criteria is structured using the template
Here are 3 examples:
Checkout process functionality
Advertising campaign
Marketing campaign (Did you know you could use Scrum for marketing)
See more acceptance criteria examples and learn to write how to create your own or learn other essential scrum terms.
Acceptance criteria is written using the following structure:
Learn more about how acceptance criteria is used in Scrum and explore the essential Scrum glossary.
Acceptance criteria is broken down into three parts.
Learn more about templates for writing acceptance criteria or learn other essential scrum terms.
A user story focuses on the identity, goals and motivations of the user you’re designing for. It emphasizes the why of the new functionality.
Acceptance Criteria focuses on the action taken by the user to meet their goal. It highlights the what of the new functionality.
See more acceptance criteria examples and learn to write acceptance criteria or learn other essential scrum terms.
Acceptance criteria is specific to an individual task, but the definition of done applies to all work done by a team. Acceptance criteria answers the question, “What will be true when this task is completed.” The definition of done answers the question, “What are we committing to do every time we complete a task?”
See more examples and learn to write acceptance criteria or learn other essential scrum terms.
Are you striving to align your goals with your values and passions?
Wondering how to measure progress or break down large goals into manageable steps?
Are you ready to transform your dreams into reality?
Our Goal Focus Guide + Worksheet is designed for you to discover how effective goal setting can transform your personal and professional life.
Download the Goal Focus Worksheet