Backlog "pre-grooming" artifacts: images, mockups, etc.

It is reasonable to expect the PO to include these assets if they clarify scope to the Development Team or otherwise express business value.

- UI mockups or wireframes can help clarify scope, and as such the PO should include them before Sprint Planning.
- Image assets are unlikely to clarify scope or describe business value...they are more likely to represent components of the implementation. Gathering and leveraging these assets should form part of the Development Team's Sprint Plan. This could be done as tasks, as you suggest.

Be careful not to do too much upfront planning. The team need to know what is needed and why, but not all details. If you spend time trying to specify all aspects of a requirement and spoon-feed this to the team you are loosing the wisdom of the crowd. Maybe there is an alternate way to accomplish the same value that is overlooked? Also make sure the PO use the team to decompose larger stories into smaller.

I would say for sprint *grooming*, the PO should bring what he/she thinks is sufficient to describe the desired functionality. The team will give feedback as to where the requirements need improvement.

For sprint *planning*, the PO should have gotten answers/decisions on that feedback.

Depending on team/company process, the UI could change considerably during implementation. Try to avoid the business making UI decisions solely if possible as developer input can be very valuable both in usability and effort.

My question really is specifically about artifacts needed to implement a story.

I think that the team is capable of estimating the stories without the assets; however, the artists creating the assets is not part of the Scrum Team and I have concerns that if we estimate the stories without the assets that we'll spend a disproportionate amount of developer time getting those assets.

Consider the example of a story to replace a set of icons with a new set. This is a very simple amount of work and would probably be estimated at around a single story point or two. If we estimate this story and take it into a sprint, we're comitting to completing the work even though we don't have the assets to be able to do so. If the artist drags their feet, has other priorities, or the developer has to spend a significant amount of time working with the artists to get the assets, actually implementing the story may take a lot more effort than the 1-2 points would indicate.

How should this situation be approached? For stories that require an asset from an outside party, how do we account for the indeterminancy in the amount of time it will take to acquire those assets?

This is why the team should be cross-functional and have all the necessary skills to build an increment. This includes developers, testers, UI design, business analysts or whatever skills that are required. Ideally there should be no dependencies to people outside the team. External dependencies always means risk.

In Scrum, a Development Team must have the skills and resources to take each Sprint Backlog item to completion, such that it meets the Definition of Done. In short they must own their process.

From what you say, this team does not own its process. They have dependencies on non-team members which can lead to impediment. Including the artists on the Development Team *might* be an option but that could mean introducing skill silos that are impossible to remedy.

Another option, as you suggest, is to get the Product Owner to supply the necessary assets. The development team will own their process from that point onwards and should be able to sprint successfully. However this is masking the problem, because the PO is effectively having to supply part of the implementation.

A better option - though it would be hard - is to extend the agile transition to include the artists. In truth, they should be sprinting as well since they are supplying assets that contribute towards delivery. They should integrate with other Development Teams in order to produce potentially releasable increments.

Scaling agile ways of working is hard, but it sounds as though your company is at the point where the matter has to be broached. Perhaps the best thing to do is to make the impediments your team face in securing the assets as transparent as possible. If you've got a physical Scrum board, stick day-glo post-it notes on the impeded stories that scream BLOCKED. The Scrum Master's responsibility will then be to coach the organization, starting with the artists, on how to sprint in a more integrated and timely manner. Like I said, agile scaling is hard...

I'll echo the comments about the scrum team needing to be cross-functional/able to do everything that needs to be done to complete the story. This really helps and if you find yourself in a position where you are reliant on external resources, see if you can figure out a way to get that expertise within your team. As a practical example, I challenged the team as to whether they needed mockups or could not provide them themselves. It could be they are relying on "the way things were done". Mostly, they didn't need mockups and were deferring to old processed. Sometimes, they needed UI expertise that did not exist in the team.

When they needed external expertise, when estimating stories we would add an assumption that the UI guidance was done (i.e. we had mockups). But this assumption means the story should not enter the sprint backlog until that was complete. We cheated on this in terms of putting stories in the current sprint that had dependencies on external resources, but in a sense the team had an out if the story was not complete... the assumption was not complete in time.

A more hardcore scrum team would not allow the story into the sprint backlog if it was not able to complete it without any dependencies on any external resources. I think that depends on your team. Certainly, I would not argue against any team who said "we cannot include this in the sprint because we cannot complete it without reliance on anything that cannot be done by the team itself".

I'm going to see what we can do to get the artists resources added to the team for future sprints. For now, we're working with the PO and the artists to try to get the art assets ahead of time and when we can't we're going to build in a bit of extra effort into our estimates to account for having to get those assets during the sprint.

Thanks very much for all of the feedback, your opinions and thoughts we very valuable in helping to decide our course of action.