What we need is an abstraction that will drive each sprint[.]
This is commonly known as the Sprint Goal. The Sprint Goal is an essential (but often overlooked) component of successful Scrum implementations.
We have a "heavy" story that cannot be decomposed into smaller stories. It will span several sprints.
This will cause you pain in the long run. It's very rare that an epic can't be decomposed into right-sized stories, but it can happen if:
- You have too many hidden dependencies in your stories.
- Your Product Backlog doesn't include sufficient spikes or non-functional requirements as user stories.
- Your sprint length is too short to accommodate your expected story sizes.
- Your stories include speculative functionality, rather than just the minimum releasable feature needed for a given Sprint Goal.
Your "heavy" story likely suffers from more than of of these problem areas, and I suspect it could be classified as a complex story. In User Stories Applied Mike Cohn says:
Unlike the compound story, the complex story is a user story that is inherently large and cannot easily be disaggregated into a set of constituent stories. If a story is complex because of uncertainty associated with it, you may want to split the story into two stories: one investigative and one developing the new feature.
In other words, such stories can certainly be decomposed, but the proper level of decomposition may first require changes to the way you construct stories or manage the Product Backlog. These changes are definitely worth investigating if the alternative is committing to an epic that ignores the framework's basic iterative principles.
Guidelines for Granularity
We can decompose the story into tasks all right, but tasks seem to be abstractions that are only a few hours long.
This is fine. Granularity is a matter of taste, but here are some widely-accepted Scrum granularity principles:
- Tasks should be sized so that they can be "done" or "not done" within one half-day to two business days.
- User stories must be sized to fit within a single sprint.
If tasks get much bigger, they become hard to estimate accurately. Make them too small, and they just increase process overhead.
Any given user story, though, must fit within a single sprint before it is accepted. Otherwise, you ignore the time-box principle and fall into the "20% of the story is 80% done" trap.
Use Your Sprint Goals as Story Filters
What we need is an abstraction that will drive each sprint...[towards] a well defined deliverable[.]
This is the primary purpose of the Sprint Goal. Each sprint, the Product Owner and the Team should agree on an over-arching Sprint Goal that captures the spirit of the minimum releasable increment for the sprint. Stories that don't address the Sprint Goal should probably be filtered out or de-prioritized by the Product Owner during Backlog Grooming or Sprint Planning.
Another use of the Sprint Goal is to provide the fundamental measure of success for the sprint. By definition, any sprint that satisfies its Sprint Goal is a successful sprint.
It's also not uncommon to have sprints that don't produce a releasable feature (e.g. sprints dedicated to non-functional requirements, tool-chain or process improvements, or story spikes). In the case of story spikes, for example, a Sprint Goal like:
Review the available literature on the effectiveness of embiggening a Jabberwock.
might be perfectly appropriate. Such a goal is measurable, possibly demonstrable, and most certainly a candidate for rigid time-boxing.
Scrum without Sprint Goals is somewhat akin to flying without an airplane: it might be conceptually simpler to just flap your arms, but you are unlikely to arrive at your intended destination.