We have a "heavy" story that cannot be decomposed into smaller stories. It will span several sprints.
We can decompose the story into tasks all right, but tasks seem to be abstractions that are only a few hours long.
What we need is an abstraction that will drive each sprint - with a well defined deliverable (similar to a story, but internal), points estimation etc. What is smaller than a story, but bigger than a task? How is something like this usually handled?
On the occasions this has happened with my teams, we look for the smallest testable slices we can make, even if we know we wouldn't release them. For example, we were integrating with a 3rd party and wanted to do single sign on between them and our site. Our story was:
In order purchase products on the 3rd party site
As a registered customer
I want to log in using my existing information
It's kinda hard to break so it still has any customer value but there was a couple of weeks effort needed to get the single sign on to work - far bigger than we'd accept into a sprint.
We ended up with a number of smaller stories which, while quite technical, all had an outcome we could demo to a non-technical product owner. To get there, we looked at what steps the team needed to take to get there technically and identified where there were outcomes that the PO was happy to verify.
We still had a couple of large chunks with no verifiable outcome though. To get round this, we created a web page within our app that would output things like user IDs, user roles etc that are passed to the 3rd party so the PO could see the app was doing something and getting the right information out, even though it wasn't doing anything with the data yet.
We also colour coded the broken out stories that were part of the big story so we made progress of the whole feature visible on our board.
Not ideal but that's the best approach we've managed so far.
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:
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.
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:
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.
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.
Are you sure you cannot split the story?
If you have for example some story about "user can subscribe to receive weekly emails" , you could split it into something like "system can send emails", "system can register users to receive emails" , and then "user can subscribe", or something like that.
Can't you separate your story in a similar way?
kthxbai
What we need is an abstraction that will drive each sprint...
Usually stories are used to drive the sprint. Stories should have clear acceptance criteria so that everyone involved, can understand the state of the story. A story should be accepted by the PO as soon as possible (not at the end of a sprint or in the sprint-review).
Usually each story is broken down into tasks which are roughly between 1h. -1d. With this you can track your sprint tasks-burn-down using a chart. This helps you to recognize patterns like to fast or slow in order to drive your sprint. If you start with 100 tasks for a 2 week sprint you measure each day how many are still open (including brand new ones).
Some very mature teams even do not use tasks, only stories, which they burn down as described by Jeff Sutherland. They have around 100-200 stories which they track in a story-burn-down chart.
Another factor is the bigness of a story. I always make sure stories are estimated (with planning poker or similar) using the so-called Fibonacci range 1,2,3,5,8,13,... Then a let the team choose the upper limit of splitting: usually an 13 or an 8 sized story needs to be splitted (vertically, not like per sw-arch-layer) before it can be worked on in a sprint.
Regarding story splitting strategies see:
I'll give you a direct answer: there is nothing smaller than a story but larger than a task.
The good news is, there are almost no story that cannot be broken down.
For example, say your story is "as a user, i want to be able to frobnicate the jimjab", and that's definitely a month of work for several people. What do you do? Likely, doing this requires a database change. So, write a story: "as a developer, i need the database changed so that I can implement the "frobnicate" story.
Maybe you need to improve the test harness so you can validate the jimjams: "as a tester, I need the test harness modified so I can test the "frobnicate" story.
Maybe the superclass of the Jimjam class must be extended: "as a developer, I need the MasterJab class to be extended so I can implement the "frobnicate" story.
And so on.
Spend quality time thinking about it, and I'm certain you can break your story (which is actually an epic) into sprint sized stories. Tell yourself you can do it, and it will happen.
If the story is too large to fit into a sprint then it should be an epic. You would then break this epic down into smaller stories and then break these down into tasks. In that way you can spread the completion of the epic over several iterations while always being able to complete the stories that make it up (and therefore hit your sprint goal).
If you can't split the story into parts that are small enough to complete in an iteration then there's a problem with how the story has been written or with the techniques you are using to decompose it. It doesn't matter (in my view) whether the tasks will only take a few hours but if you think these are too small then you could try and bundle a few related tasks together so that you don't feel like you're measuring something that's too small to meaningfully measure.
