Should all required user story assets be available before sizing a story or starting the sprint?

Question

I am a developer. Sometimes we have stories which will require some sort of asset that is not in the control of the dev team. A common example would be that the story calls for a new piece of UI to be added, but another party/department will be providing the correct copy (text) for this.

I may be told the requirements for a new story are something like:

"We need to add something across the top here. It'll be no more than two lines of text and maybe 5 bullet points. It needs to look prominent and visually interesting."

At this point, I have no idea what the copy will actually be, but need to size the story anyway, based on what I think it roughly entails. When it comes to sprint planning, the story is pulled into the sprint and often I am told the copy will be ready by a certain day, which falls during the upcoming sprint itself. So the story is entered into the sprint with a size, but without the assets available.

I find these stories often take me longer than I estimated, or I put off starting them because the assets aren't ready yet and I don't know when they will be. Sometimes the sprint ends and the assets still weren't available for me to start.

If I need to do some design work it sometimes takes twice as long it should because I don't really know what content I'm designing for. Other issues that crop up are things like I start the story and finish the UI, but then the copy becomes available. So I need to revisit the story and enter the copy. Then I might need to work on it again to make it look right now that the final copy is in. All this time I can't really mark the story as Done and this kind of story sitting in "In Progress" for days half finished clutters my mind and affects my focus on another area of development.

I feel like no story should be entered into the sprint unless all the assets are finalised and available. Is this an unrealistic expectation? We are a small company and don't really have a dedicated Scrum Master - it's basically me, but as I am also a developer and don't necessarily have time to be chasing for assets during a sprint (and I find it distracting).

What should we be doing?

Answer 1

TLDR: Don't accept anything into the Sprint if the Scrum Team cannot complete it in its current form.

---

From the Scrum Guide:

Scrum Teams are self-organizing and cross-functional. [...] Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.

The ideal Scrum solution is to take the work of creating these requisite assets and move it into the Scrum Team itself. Either by adding people to the Scrum Team or by adding skills to the existing members.

If that is not possible for whatever reason, then I would suggest you reject any work that the Scrum Team is unable to complete on its own. Until such time that the Scrum Team is able to complete it.

Answer 2

I would advise that any team is within their rights to not pull something into a sprint that isn't ready. If you decide you need all copy before it is ready, then that is your prerogative.

However, I would also coach any team to strive to be more responsive than that if they can without compromising their own team or the quality of the product. The situation you describe is not uncommon. The flaw in the thinking I usually see here is the assumption that one feature can be effectively developed by 2 different groups without working closely together. Designing a great UI is a collaborative effort of code, visual design, content, and experience. Ideally, all of these skills should be in the Scrum Team. However, if you were in the situation where you couldn't have this, it would definitely be important to build practices that allow those individuals to effectively collaborate in the sprint.

Answer 3

External dependencies generally have two effects on a Scrum Team: they reduce predictability and they reduce efficiency.

Predictability is difficult as the dependency is outside of the control of the team and plans may often have to be changed. Efficiency is impacted as external dependencies often lead to context switches, where the teams has to stop work on some items or quickly start work on other items based on the status of a dependency.

The extent of these impacts will vary as follows:

• The team has external dependencies and needs to bring items with dependencies into sprints - high impact
• The team has external dependencies but can hold off on bringing these items into sprints until the dependency is resolved - medium to low impact
• The team has few if any external dependencies - little or no impact

So the question that your team faces is: "How much of an impact on predictability and efficiency are we willing to accept?"

The answer will depend on the organisation and the nature of the work you do.

One approach worth taking is treating external dependencies as opportunities to adapt. Every time one happens, discuss it in your retrospective and see if there is some way of avoiding it happening again in the future. For example, perhaps the availability of copy could be made more predictable by very careful scheduling?

Answer 4

I feel like no story should be entered into the sprint unless all the assets are finalised and available. Is this an unrealistic expectation?

No that's perfectly acceptable. As a team you should have the agency to decide what you work on when the sprint starts. If a ticket is not in a state where it can be completed when the sprint officially started, it's not ready and should not go into the sprint.

Answer 5

I agree with most (if not all) statements: a team shouldn't accept an item into a Sprint if the team isn't comfortable with it.

To shed some lights in another part of your situation:

At this point, I have no idea what the copy will actually be, but need to size the story anyway, based on what I think it roughly entails.

This quote for me is the key - a Scrum team is expected to understand the application enough to be able to have at least a rough idea of what's being requested. This requires understanding the business. That's what usually the Product Owner will help you with. You may not have a concrete idea of what you'll receive, but your PO should be able to give you some hints on how it'll look like. And then, with that information, you can deliver.

This is very important to avoid a massive pushback on all requirements. Most of them are refined on the fly - phrases are changed, sizes are tweaked, colors shuffled, all based on demos and feedbacks - but you should target to be able to have something minimally delivered based on the original assumptions. Better deliver something valuable that can be improved later on than no delivery.

In your case, I'd suggest to, on top of pushing back on most requirements that are unclear, to also understand why your PO cannot provide at this rough idea about the requirement. Chances are, there's no PO - or the PO is not facilitating as he should be doing.

Answer 6

Misguided principle of the Scrum under the Agile framework. Agile doesn't necessarily mean you work under uncertainty all the time. It does mean you adopt and accept changes as part of backlog, not within the Scrum.

A common misconception of the team I have worked with is that you can change scope of the sprint during the sprint. This should not be the case because then you are losing velocity. So, within the sprint the scope is fixed.

If the story is not clear in terms of requirements, ideally it goes to the backlog and Product Owner (PO) has to take ownership to get things done.

I also noticed grooming is not followed; as part of grooming exercise, Development Team (DT) should catch this and needs to inform the PO. It is PO's responsibility that the backlog is updated with the necessary requirements.

Important: it is all under the rights of the DT to say no if the story doesn't have all the needed information. Scrum Masters will support this.