1.Why Scrum for Real-time Graph Teams (Memgraph) is worth getting right
A large part of the module covers streaming ingestion as a first-class design constraint during refinement. Unlike a static graph loaded once, a Memgraph deployment is continuously updated by incoming events, and the module teaches teams to ask, during refinement rather than during an incident, what happens to a query's correctness and speed while the graph underneath it is actively changing. Scenarios include a Sprint where a feature that worked perfectly in testing degrades under live streaming write load, and a Sprint Review where a stakeholder needs to see the system respond under simulated real traffic, not a static snapshot, before they will trust the Increment.
2.How it works in practice
The module closes on capacity planning and Definition of Done criteria tuned for real-time graph work: memory budget per node and relationship type, tested behaviour under concurrent read and write load, and a documented latency service-level objective that the team actually measures against, rather than an aspirational number nobody checks after the Sprint Review ends.
3.Role reality
Streaming graphs punish teams that estimate like a batch job and demo like a slide deck.
| Textbook theory | Delivery reality |
|---|---|
| Real-time means as fast as possible. | Real-time means fast enough that the decision is still useful. Negotiate the freshness SLO in plain language, then defend it. |
| A pipeline that works in staging works in production. | A pipeline that works at average load and dies at peak is the standard Memgraph trap. Peak drives the estimate, not average. |
| The Definition of Done is about correctness. | Correctness under peak event rate is the Definition of Done. Untested at peak load is a hypothesis, not an Increment. |
| More MAGE algorithms mean more capability. | Every algorithm integrated speculatively costs memory and latency the team pays for on every query, not just the ones that use it. |
4.Core delivery pillars
Four habits for a streaming graph Sprint that survives contact with production traffic.
Every real-time graph PBI states the source stream, the expected event rate, the freshness SLO and the p95 query latency budget before it is estimated.
Back-pressure at peak event rate is the classic failure. If nobody in Refinement can name the peak rate, treat that as the first impediment.
Replace one nightly report with one live pattern for one product line. That is Sprint-sized. Migrating all analytics is not.
Demo in that order and stakeholders trust the freshness number because they watched it happen, not because they read it on a slide.
5.Metrics that matter on a real-time graph team
These expose whether the system is honest under real load, not staged load.
Event to queryable graph state, measured at peak, not average.
What the business actually feels when it asks the graph a question.
Times the stream backed up and freshness silently degraded.
Stream, model, query or hardware. Track the cause, not just the miss.
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 17.3: Game: capacity for a streaming graph Sprint
- Lesson 17.4: Game: pick the Sprint Goal for a real-time graph iteration
7.Common mistakes and why they fail
Writing backlog items with no latency target
Treating speed as a nice-to-have to be optimized later, when for a real-time graph system the millisecond response time is the actual acceptance criterion, not an afterthought.
Testing against a static graph snapshot only
Validating a feature against a graph that is not receiving live writes, then discovering in production that concurrent streaming updates change both correctness and latency.
Ignoring memory budget until the system runs out
Adding node and relationship types without tracking their in-memory footprint, since an in-memory graph database has a hard capacity ceiling that batch-oriented graph systems do not face the same way.
Demoing a query result without demoing the load it will face
Showing a fast response at Sprint Review under artificially quiet conditions, without also showing the same query under realistic concurrent streaming write volume.
8.Questions worth asking before you commit time to this
Why does latency belong in the Definition of Done for a real-time graph feature?
Because for an in-memory, streaming graph system, a correct answer that arrives too late is functionally a wrong answer. If the team does not test and agree on a latency budget as part of done, the Increment has not actually met the need it was built for.
How should a team estimate work on a continuously updating graph?
By explicitly testing the feature under simulated concurrent write load during the Sprint, not only against a static snapshot. Refinement should ask what happens to correctness and speed while the graph is actively changing underneath the query.
What capacity planning belongs in Sprint Planning for Memgraph work?
A running estimate of memory footprint per node and relationship type, since an in-memory graph has a hard ceiling that a disk-based system does not. Adding schema elements without tracking this is how a team runs out of capacity mid-Sprint with no warning.
What should a Sprint Review for a real-time graph feature actually demonstrate?
The feature responding correctly under realistic concurrent load and streaming writes, not a quiet, artificially calm demo environment. Anything less does not give stakeholders real information about whether the Increment will hold up in production.
9.What to remember
- Three numbers every real-time graph PBI must name: event rate, freshness SLO and query latency budget
- Why back-pressure is the failure mode that passes in staging and breaks on the busiest day
- A Sprint Review order that makes a freshness number believable
10.Where this sits in the Scrumling course
Refine, estimate and slice work when your graph is in-memory, streaming, and expected to answer in milliseconds, not overnight.
About 35 minutes of lessons and decision scenarios.
- Lesson 17.1: Why real-time graph work is a different Sprint
- Lesson 17.2: Writing PBIs for streaming graph work
- Lesson 17.5: Coaching stakeholders on 'live enough'
- Lesson 17.6: Retros for real-time graph teams
- Lesson 17.3: Game: capacity for a streaming graph Sprint
- Lesson 17.4: Game: pick the Sprint Goal for a real-time graph iteration
Assessment: Scrum for Real-time Graph Teams (Memgraph) quiz