1.Why Scrum for Knowledge Graph Teams (Neo4j and Friends) is worth getting right
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.
2.How it works in practice
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.
3.Role reality
The left column is a Refinement slogan. The right column is what happens when someone actually opens the database.
| Textbook theory | Delivery reality |
|---|---|
| A PBI is a PBI, regardless of data model. | A PBI written by someone thinking in tables produces table-shaped software over a graph database, which is the worst of both worlds. |
| Estimation is about task size. | Estimation is about traversal depth and average node degree. Nobody can estimate a depth-5 query on an unknown-degree graph honestly. |
| The Sprint Review is a demo of the feature. | The Sprint Review is a demo of a pattern. Show the picture before the query or the stakeholder will not trust the answer. |
| Recursive queries are just another line of Cypher. | Recursive queries on a super-node explode. If nobody knows the average degree, that is your first impediment. |
4.Core delivery pillars
Four habits that keep graph Sprints estimable and demoable.
Ask three questions on every graph PBI: which nodes, which relationships, which traversal. Skip any one of them and the estimate is a guess.
State whether the answer is a list, a count, a subgraph or a score, and note the expected node count and average degree before anyone estimates.
A depth-3 traversal on a well-behaved graph is trivial. Depth-5 on a super-node is not. Estimate the risk separately from the happy path.
Most stakeholders will never learn Cypher and should not have to. A shared drawing of the pattern is the contract for what the query has to answer.
5.Metrics that matter on a graph team
Numbers that expose modelling and traversal risk before it reaches production.
Was the miss modelling, traversal depth, or data volume. Track it, not just the miss itself.
The number that decides whether a traversal is safe or a landmine.
What the stakeholder actually feels, not the average that hides the worst case.
How long from an agreed drawing to a working, reviewed query.
6.Situations you will be asked to handle
The module puts you inside 2 decisions rather than asking you to recognise the right answer on a list. Each one is a situation practitioners meet, with several defensible options and consequences that follow from the one you pick. The scenarios below are the shape of the judgment the subject demands.
- Lesson 15.3: Game: estimating recursive graph work
- Lesson 15.4: Game: pick the Sprint Goal for a graph iteration
7.Common mistakes and why they fail
Estimating graph queries like relational queries
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.
Modeling every possible relationship instead of the ones you query
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.
Slicing backlog items by node label instead of by traversal
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.
Demoing a graph visualization instead of a working query
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.
8.Questions worth asking before you commit time to this
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.
9.What to remember
- A shared vocabulary for writing graph PBIs that stakeholders and developers can both estimate against
- Why recursion and super-nodes are where graph estimates quietly die
- A demo order that makes stakeholders trust a Cypher query result
10.Where this sits in the Scrumling course
Refine, estimate and slice work when the mental model is nodes and relationships, not rows and tables.
About 35 minutes of lessons and decision scenarios.
- Lesson 15.1: Why the graph mental model changes refinement
- Lesson 15.2: Writing PBIs for graph work
- Lesson 15.5: Coaching stakeholders who think in tables
- Lesson 15.6: Retros for graph teams
- Lesson 15.3: Game: estimating recursive graph work
- Lesson 15.4: Game: pick the Sprint Goal for a graph iteration
Assessment: Scrum for Knowledge Graph Teams quiz