Why knowledge graph work needs its own Scrum playbook
Graph teams working in Neo4j or similar property graph databases run into a specific refinement problem: a backlog item written the way a relational team would write it, add a table, add a field, does not map onto a graph model where the real design decisions are which relationships to model explicitly, which to compute at query time, and how deep a traversal needs to reach before it becomes too expensive to run live. This module starts by teaching a graph-specific slicing heuristic, ship one traversal pattern or one query use case end to end, rather than building out an entire schema of node labels and relationship types before anything is queryable.
A significant part of the module is dedicated to estimation, because graph work has a cost curve that does not resemble typical CRUD estimation. A two-hop traversal that returns results instantly in a demo graph of a thousand nodes can become a multi-second query at production scale, and the module teaches refinement questions that surface this risk before a Sprint commitment is made: what is the expected fan-out at each hop, is the pattern indexed, and has anyone tested it against production-scale data. Scenarios walk through a Sprint Planning session where a seemingly small backlog item hides an unbounded traversal, and a Sprint Review where a graph visualization impresses stakeholders without anyone checking whether the underlying query is actually usable in production.
The module closes on Definition of Done criteria specific to graph systems: relationship cardinality documented, query performance verified at realistic scale, and a clear answer to whether a given fact should live as a graph relationship or be computed on demand, since over-modeling every possible relationship is a common way graph schemas become unmaintainable. Cypher-flavoured examples throughout keep the guidance concrete rather than generic.
Mistakes teams make with this material
Assuming a traversal that returns fast on a small development dataset will perform the same way in production, without checking fan-out or existing indexes on the relevant relationship types.
Adding relationship types speculatively because they seem semantically correct, which bloats the graph schema and slows writes without serving any actual query pattern in the backlog.
Writing tickets like add the Person node or add the Company node instead of slicing around the query or use case those nodes and relationships need to support together.
Showing a nice-looking graph diagram at Sprint Review without confirming the underlying Cypher query actually returns correct results within an acceptable time at real data volume.
Questions people ask
How should a Product Owner slice a knowledge graph backlog?
Around a specific traversal or query use case a stakeholder cares about, end to end, rather than around individual node labels or relationship types. A backlog item is done when the query it exists to serve returns correct, performant results, not when a schema element exists in isolation.
What is the biggest estimation risk in graph work?
Fan-out at each hop of a traversal. A pattern that looks trivial on a small dataset can become exponentially expensive as relationship density grows, so refinement should always ask about expected cardinality and indexing before the team commits to a Sprint estimate.
Should every real-world relationship become a graph relationship?
No. Model the relationships your queries actually traverse. Facts that are better computed on demand, or that would explode the graph's density without serving a query pattern, are usually better left out of the schema entirely.
What does Definition of Done look like for a graph feature?
It should include verified query performance at realistic data scale, documented relationship cardinality assumptions, and correctness checks against representative graph data, not just a passing unit test against a tiny fixture graph.
A question from this module's assessment
One sample question with the reasoning, so you can judge the level before you start. The rest of the assessment stays inside the module.
Which is the strongest shape for a graph PBI?
- 'Add fraud detection'
- 'Given a Customer, traverse OWNS to Accounts and LOGGED_IN_FROM to Devices up to depth 3, return shared-device clusters over 24 hours'
- 'Make it faster'
- 'Add a report'
A graph PBI names nodes, relationships, traversal, answer shape, and volume assumptions. That is what makes an estimate honest.