When you only need a development team member for a couple of hours

Have you talked to the graphic designer to determine how long it will take them to do the work and what their availability is based on other projects they have? That would probably be the first step, plus involving the people doing the work with the decision on how to do the work is more consistent with Agile values and principles.

That said, B is probably a better option. But it would be better to come to that conclusion as a group, including the designer and perhaps the designer's manager. Perhaps there is an opportunity to think about how to generally approach the problem of such specialists in the organization.

Do the Developers consider the risk of having her as an external dependency to be acceptable? They would remain accountable for meeting the Sprint Goal and the Definition of Done, even though she will be doing part of the work.

The problem here is empirical inspection and adaption is not possible as you have a "developer for a day". You have no historic sprints to determine velocity. 

The team should have the skills to forecast work to be completed within the definition of done within the time box (AKA 2 week sprint). Having graphics done outside of the team breaks this rule and is not Scrum.

Scrum is also created to manage complex systems, and wireframes or design work does not fall into this category.

In this case, I would recommend having the graphical work done and provided as a resource to the PBI. Think of it as some refinement needed before the PBI can be added to a Sprint backlog.

B: Our team suggested we'd see her as a subcontractor and just have a separate meeting with her, plan the designs, and wait for them to be delivered, then implement and test them ourselves.

Sharing some of @Thomas Owens' concern on this.  Has it been discussed with the Graphics Designer to make sure they can do the work in time for the team to finish their work?  For example if they can do it in 2 hours but the only time she has available will be the afternoon of the next to the last day of the Sprint, is that good enough to complete the Sprint Goal?  



I have an Option C:  Have the designer do the work sometime in the next 2 weeks and the team can plan the work that needs it for a future Sprint. 

That is a method that I have used with teams in the past.  In essence the work to create/provide wireframes is part of the refinement.  It is an external dependency and until it is done the Scrum Team cannot start their work. The wireframes can be discussed with the designer outside the activities in the Sprint and be better prepared for the implementation.

Do the Developers consider the risk of having her as an external dependency to be acceptable?

To build on this, how likely is it that such a dependency still exists, beyond the anticipated couple of hours?

For instance, after releasing these graphics, could it be that further graphic design work is needed, perhaps to respond to feedback and iterate on what has already been done, to support additional screen resolutions, or to apply a consistent user experience, as other functionality evolves?

In essence, could this be an early indicator of an ongoing need within the Scrum Team?

Thank you so much for your insights.

Today we had a meeting where we asked the dev team Ian's question: If they'd feel comfortable to be responsible for someone's work who's not on the team. After a bit of discussion about responsibilities in general, and on whose shoulders they lie concerning the designer, they decided they didn't want that accountability.

The team then came to the same conclusion as the mentioned option C (By Garry and Daniel): To have all the external work be completed before a sprint and provided as a resource to the PBI.



Then the Dev team decided to contact the designer's manager (incidentally also the PO) to submit those graphics before the dev team would need said graphics. 

So thanks for all the insights, together they made a great answer.

To reflect:

I'd like the graphics designer to be part of the development team, as this would be Scrum.

The solution for now works out well, but in the future I'll be more vigilant for missing skills/assets which are needed while putting together the development team.



Cheers,

Johannes