Creative Scrum: Doing Research

Finding the problem that needs solving.

July 31, 2023
Creative Scrum research paper

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.

Sometimes you just have questions about key Scrum terms. Download the Scrum terminology cheat sheet.

Who's the user?

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

Interviews were the primary method for my research. I chose interviews for two reasons:

  1. Interviews provide excellent qualitative data.
  2. Interviews helped me build relationships with people.

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.

Internal Questionnaire.

  1. Tell me about your role.
  2. Describe what you do in an average week.
  3. Describe your interactions with other C1M staff.
  4. Describe your interactions with clients/partners.
  5. Describe how you get assigned work.
  6. How would you describe your goal for the work you're assigned?
  7. Take me through your workflow on a project.
  8. Explain how this workflow fits in the larger C1M workflow.
  9. What other C1M processes influence your work?
  10. How is what you do different than what other C1M creatives do?
  11. What are some tricks you've learned to get work done?
  12. Describe some friction/pain points in your job.
  13. What contributes to these pain points?
  14. How do you deal with them?
  15. How would you measure the effectiveness of the assets you deliver?
  16. If you could change 1-3 things about how C1M operates, what would it be?
  17. Anything else you would like to share?

External Questionnaire

  1. What is your role?
  2. How do you interface with C1M?
  3. Describe the projects you've requested C1M partnership on.
  4. How many requests have you made in the past 12 months? What were they for?
  5. Is there a cycle to your requests? If so, describe.
  6. Describe the process leading up to engaging with C1M.
  7. Describe the process for submitting a request to C1M.
  8. Describe the interaction with C1M between requesting work and receiving assets.
  9. Describe the process of receiving the assets.
  10. Describe the process of feedback/review/follow-up after assets are delivered.
  11. How would you measure the effectiveness of the assets you received from C1M?
  12. How would you measure the effectiveness of your projects?
  13. Think about a past project with C1M. If you could go back and change one thing, what would it be? Why?
  14. Anything else you would like to share?

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.

Organizing the Data

After a batch of interviews, I would take a few and process them using the following steps:

  1. Reread the notes for familiarity if I hadn't done the interview that day.
  2. Digitize quotes and observations by putting them on a digital sticky note.
  3. Synthesizing the sticky notes by organizing them into groups.

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.

Time with people

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:

  1. There is a more complex set of users.
  2. You're probably going to be working with these people in the new system.

Interactions take two.

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. 

Related Guides

No items found.

Users are people too.

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.

Action Plan

For a deeper dive check out these additional phases of my creative scrum journey.

Frequently Asked Questions

Scrum team

How does a scrum team work?

The scrum team is made up of the product owner, scrum master and development team. They each play important roles.

  • The product owner maximizes the value delivered by the product.
  • The scrum master maximizes the impact of the development team.
  • The development team transforms the product vision into reality.

Learn more about how a scrum team works together. Then browse the most common terms in a Scrum glossary and learn what is Scrum.

Is a Scrum Master a project manager?

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.

Can a scrum master be a developer?

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.

What’s the right scrum team size?

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 design

What are the three pillars of Scrum?

Scrum is founded on three essential pillars, and each leads the team to ask a critical question.

  1. Transparency. How does this make things more visible?
  2. Inspection. Where does this create space to evaluate?
  3. Adaptation. When does this encourage growth?

Learn how to apply the three pillars of Scrum and then explore the most common terms in a Scrum glossary.

What are the values of Scrum?

There are five values critical to the practice of Scrum: commitment, courage, focus, openness, and respect.

  1. Commit to achieving the goals of the Scrum Team.
  2. Courage to do the right thing and work on challenging problems.
  3. Focus on the Sprint's work and the Scrum Team's goals.
  4. Open about all the work and the challenges with performing the work.
  5. Respect each other to be capable, independent people

Learn how to align Scrum values with your organization and then explore the most common terms in a Scrum glossary.

What is the sprint goal in scrum?

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.

Scrum backlog

What is the backlog in Scrum?

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.

How are the product backlog and sprint backlog different?

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.

What is a PBI (product backlog item)?

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.

What is the Scrum sprint backlog?

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.

What is the Scrum product backlog?

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.

Scrum User Stories

What is a user story?

They keep the team focused on the value they create for the end-user and are written using the following format:

  • As a… [user]
  • I want to… [goal]
  • So that I can… [motivation] 

See examples of user stories to learn to write your own and explore the essential Scrum glossary.

What is acceptance criteria in scrum?

Acceptance criteria is written using the following structure:

  • Given that [context allowing me to take an action]
  • When [I take the action]
  • Then [a result occurs indicating success or failure]

Learn more about how acceptance criteria is used in Scrum and explore the essential Scrum glossary.

How are acceptance criteria and user stories different?

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.

What's an example of acceptance criteria?

Acceptance criteria is structured using the template

  • Given that [context allowing me to take an action]
  • When [I take the action]
  • Then [a result occurs indicating success or failure]

Here are 3 examples:

Checkout process functionality

  • Given that I’ve added all the items to my cart and I’m logged in,
  • When I click the check out button,
  • Then the checkout page loads with all my payment and shipping information preloaded.

Advertising campaign

  • Given that someone fits our ideal customer persona,
  • When they search for keywords we’re targeting,
  • Then a link to a compelling offer is displayed above the fold.

Marketing campaign (Did you know you could use Scrum for marketing)

  • Given that a customer is already receiving email communications,
  • When they visit the site and engage content related to a specific product,
  • Then they will be automatically subscribed to nurturing campaign highlighting that product. Or

See more acceptance criteria examples and learn to write how to create your own or learn other essential scrum terms.

What are story points?

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.

Agile story points

What are story points?

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.

Are Scrum story points measured in hours?

In Scrum, you are not measuring work in absolute terms like hours spent or lines of code to be written. Two reasons for this:

  1. Not everyone works at the same pace or has the same set of expertise and experience.
  2. Until you do the job, these are unknown and, at best just guesses.

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.

Do story points in Scrum always use the Fibonacci sequence?

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:

  1. Keeping story points measured in numbers is advantageous because it is then easier to calculate a team's velocity.
  2. The numbers have distinct relationship with each other making relative sizing more intuitive. The Fibonacci sequence increases such that each number is the sum of the previous two number.

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.

What is velocity in Scrum?

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

What's an example of acceptance criteria?

Acceptance criteria is structured using the template

  • Given that [context allowing me to take an action]
  • When [I take the action]
  • Then [a result occurs indicating success or failure]

Here are 3 examples:

Checkout process functionality

  • Given that I’ve added all the items to my cart and I’m logged in,
  • When I click the check out button,
  • Then the checkout page loads with all my payment and shipping information preloaded.

Advertising campaign

  • Given that someone fits our ideal customer persona,
  • When they search for keywords we’re targeting,
  • Then a link to a compelling offer is displayed above the fold.

Marketing campaign (Did you know you could use Scrum for marketing)

  • Given that a customer is already receiving email communications,
  • When they visit the site and engage content related to a specific product,
  • Then they will be automatically subscribed to nurturing campaign highlighting that product. Or

See more acceptance criteria examples and learn to write how to create your own or learn other essential scrum terms.

What is acceptance criteria in scrum?

Acceptance criteria is written using the following structure:

  • Given that [context allowing me to take an action]
  • When [I take the action]
  • Then [a result occurs indicating success or failure]

Learn more about how acceptance criteria is used in Scrum and explore the essential Scrum glossary.

How to write an acceptance criteria statement?

Acceptance criteria is broken down into three parts.

  • Given that [context allowing me to take an action]
  • When [I take the action]
  • Then [a result occurs indicating success or failure]

Learn more about templates for writing acceptance criteria or learn other essential scrum terms.

How are acceptance criteria and user stories different?

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.

How are acceptance criteria and the definition of done different?

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.

Ready to level up your company? Get in touch today!