What To Put In a Scope Doc
I believe this is a process that is concise, clear, and addresses more of the issues, without prescribing a solution before it is solved:
- problem
- raw idea (without designing anything... just what do we need?)
- a breakdown of the scopes into broad chunks/categories
- sketches, not designs, that communicate intention, not solution
- how interactivity works (multimedia has many elements "between the lines" that need to be thought through)
- any possible risks that can be envisioned up front can save us wasting time on unnecessary scope that we want to avoid
- any intentional no-gos (constrain the scope by clearly stating what NOT to do)
From this sort of document, developers + designers can sit down and talk about how they might go about realizing these requirements; which is a separate concern from the product intentions and can be handled differently by different teams as they see fit. It's a lot harder to be agile when everything is already decided. There may be alternate solutions or tradeoffs or data structures or compositions or syntheses which aren't apparent at a high level (nor do they need to be).
The goal of a scope document should be to communicate intention and desire and constrain the problem domain down to a level that can be acted upon. That's it. The design should evolve alongside the code, each informing the other. We won't know the true nature of an interactive problem until we can actually interact with it, and at that stage it might look a lot different than it did on paper. We will need to change and pivot. Our process should have that as a core tenant.