Should the content team be included in Scrum team and should we planned in the same manner as Scrum team?

Question

This is the case:

• We have one Scrum team of 7 members (developers and QA's) plus PO and SM
• We have content team of 3 members that are responsible for portal ''look'' (banners, pictures, copywrite etc.)

This is the problem:

• We have situations where development team is working in the sprint and we only use lorem ipsum and we do not have real images nor real content on the site
• Content team is not working in parallel with development team and we have situations where content team is not able to finish their work on time

Question is: - Should the content team be included in Scrum team and should we planned in the same manner as Scrum team?

Challenge is: - We do not have dedicated content members and they are always changing.

I would really appreciate your help, thanks!

Answer 1

The Book Answer:

The Scrum Guide says that the scrum team has all skills necessary to deliver a potentially-shippable increment of the product. This is specifically put into place to avoid situations like you are describing. This is a classic case of "this is why Scrum says not to do this."

There are two ways to solve this problem and be within the scrum guidelines:

1. Get content members on the team. You mentioned that those people keep changing. Do they have to? Occassional change is normal but constant change is often a challenge imposed arbitrarily with no value being added from it.

2. Build the skills into the team. Often times we silo skills into jobs titles that don't need to be. Are you doing something so specialized with content that no one who isn't an expert in that area can create the content?

Pragmatic Answer

Sometimes you just can't - for many reasons including organizational constraints outside of your control or sometimes the skills needed are just too many and varied (for example, high end video game development often hits dozens of very specialized skills) and maybe you just have to have a content team and a development team. You can still fall back to traditional project management techniques of aligning priorities. How are priorities set with each team? Can they be set by the same PO? Is there an SLA from content that can be planned around?

Also, what is the value needed from your business? Are they ok with lorem ipsum and placeholder images? Does that give you enough to learn from your stakeholders and continue building out your next product increment. It's true that in Scrum we want to get to a completely shippable product every few weeks, but where are you now? If you're currently on a 6-mo release cycle and you're trying to get it down to monthly, maybe a partial fix to this is the big step forward you need right now.

Answer 2

A Scrum team ought to be cross-functional. If content is part of the product increment that is released at the end of the sprint, then the content people should be part of the Scrum team. That doesn't mean that content tasks will be handed off to the content team, but that the content people are directly part of any planning and can provide their input early in the process. This should also avoid capacity issues where the development needs more content than the content people are able to provide.

Of course, that kind of process mostly works in theory. Your lack of permanent content people means that the team would be constantly changing, which may impede development. From a Scrum perspective, a team absolutely cannot change during a sprint.

But have you considered not doing sprints, and not using Scrum? I.e. not shipping a product increment every X weeks with all content filled in?

There are two ways to approach this:

• your development team happily continues doing Scrum, but their product does not include content. That would be managed at a later phase by the content team when they get around to it. Note that this means that development-release and public deployment would be separate events.

• you stop doing discrete increments, and use a more flexible process framework like Kanban. Kanban is good at visualizing stages of a task as it flows through your process, e.g. “in development” and “waiting for content”. Kanban also makes it easier to see where the bottlenecks in your process are, e.g. if tasks are piling up in the “waiting for content field”. But for the business it doesn't matter where the tasks are piling up, only that they that they are generally completed quickly.

Answer 3

If the PO isn't handling this coordination well, the Scrum Master can step in and try and help by increasing the communication channels between the 2 teams. You could consider including a content representative in with your dev scrum team planning sessions, and give the content team early sight of what's top of the backlog that is likely to get worked on in the next couple of sprints, so they can plan their work better to coordinate with the dev team's needs.