What: Cleaned and clarified description of the deliverable, broken out into features that make sense to everyone.
Ideally, we want both the high-level, easy-to-grok description, and the low-level, precise breakout.
eg. "Web dashboard w/ 2 tabs -- "Mobile Site", and "Mobile Apps". A contains 6 graphs: 1. Pageviews to Mobile Site (line, logscale, step=1mo), with metrics (all pageviews / month): total across all sites, alpha site, beta site. 2. ..."
Goal: Consensus around the concrete deliverable and especially its scope, including:
Clear and precise enumeration capabilities/limitations
Expectations around behavior and appearance
Rough expectations around a timeline, and some boxing on level-of-effort/the time commitment
Components:
Data Requirements, specified as precisely as possible.
We don't necessarily need to make the user sit through us hashing this out, but (imo) we do need to get them to explicitly sign off on the result.
I think we should consider it a hard requirement that any feature which requires new metric work have descriptions for:
Definitions for all metric dimensions (with datatypes) -- this means "counts" should explicitly say what dimensions are grouped and counted
Data output shape -- define rows/columns with types (including the step between rows); what defines a "key", and is it row-major or col-major?; cardinality/storage estimate; drill-downs/aggregations/rollups
Data source(s) -- both the data necessary for the computation and the origin of said data. For example, if the expectation is that we use a stream into Kraken, it is a different feature to fall back on the sampled Squid logs, as the whole implementation toolchain is different.
Data output format(s) -- can't just assume tsv if we aim to deliver certain visualizations (esp geo) -- is json, xml, or avro ok? how will the data be published? does it need to be public, or can we cron files into a shared space on stat1001?
Minimally required frequency of recomputation -- note this is different from the timestep for rows and/or rollups; this is how stale the data can be (aka, how often the job runs)
Presentation/Visualization Requirements, including any graphs, dashboards, domains, or other presentation features (pointing to existing examples if possible).
Dashboards: names, contents for each, their tabs, and the visualizations in each tab.
Questions for each visualization: graph type (line, bar, geo, etc); any specific formatting/appearance requests (custom labels? scale? timespan?)
What: List several technical solutions as options for satisfying the requirements, assessing the tasks required and the level-of-effort involved.
Goal: Find the best way to make the user happy while conserving dev effort and advancing along the trajectory of our strategy to provide insight via a robust, automated, self-service platform.
If necessary, Engineering Lead coordinates team expertise and presents results.
Everyone works together to assess, revise, and prioritize (planning poker, etc).
