Is splitting user stories into versions a valid approach?

Question

My questions is about splitting a story into versions. For example, we might have a story to allow a user to upload a file to a server. The first iteration of the story is usable by the customer but it's quick and dirty, the second adds file validation, the third version adds deltas, and so on.

The point is that these activities are probably too small to be a feature but too big to be a single story. The body of each story will contain all the acceptance criteria and other data, but what should that set of stories be named? Is it okay to say "User can upload file v1", "User can upload file v2", etc?

Alternatively, the title might add a bit more description of the functionality, but in that case it can get too long. That makes it harder to prioritize during refinement and planning. For example, if I am looking at a set of versioned stories, the prioritization decision is already codified into the title so I don't have to remind myself what it was every time I see the set of stories.

Is this a valid approach to splitting stories or prioritizing the Product Backlog?

Answer 1

In an agile system, I would argue that planning these versions before you even start on the first one is not thematically coherent. Just create a user story for what you will currently do, and address expanded features when the need for them arises.

That being said, a lot of projects don't work purely agile, and some future planning is always done - I'm referring to developers specifically here.

In these cases, I would argue that this is better encapsulated by an epic (file upload) with individual user stories:

• I want to upload a file
• I want my uploaded file to be validated
• I want the upload to only process deltas from my uploaded file
• ...

And then you can individually plan those stories across your sprints as you see fit. This way, the expansion of the file upload functionality can be tied to specific versions of your software releases.

This way, you retain oversight on the file upload feature (by inspecting the epic), while at the same time having fully descriptive stories than can be individually planned, worked on, and tracked (by inspecting the user stories of the epic).

It also gives you some freedom as to which feature to tackle when. Obviously, the general upload feature comes first, but you are able to decide at a later date whether you first want to tackle the validation or the deltas. These expansions are not strictly sequential and your proposed versioning system would wrongly imply that it has to happen in a particular sequence.

I would advise against coming up with arbitrary version schemes for anything that you want to tackle in order, because having many different version numbers to juggle makes things needlessly complex.

Answer 2

When stories were first used and written on cards put up on a wall, the title of the story was a memory-jogger for the team. The purpose was to give both the team and the stakeholder (or stakeholder representatives) a way to quickly remember the topic and frame the discussions around the feature or functionality being created or changed.

Given this, titles like "User can upload file v1" and "User can upload file v2" don't do that. They do make it clear that it has something to do with uploading files, but what does "v1" or "v2" really mean? On top of that, it implies an ordering that isn't necessarily true. If "v1" corresponds to file validation and "v2" corresponds to deltas, the team may very well be able to implement "v2" before "v1".

There's nothing wrong with titles like "file upload", "validate file upload" or "provide delta between file uploads". These titles are not too long and give everyone involved the right idea about what work is being discussed, with more details captured to further clarify the scope. Especially with today's electronic tooling (which I'd highly recommend over physical cards), it also becomes easy to update the title to reflect the agreed upon scope if that becomes necessary.

Answer 3

TL;DR

If you are following the Scrum framework, work should be iterative by nature. It should also be time-boxed, so user stories and Product Backlog items should not carry history.

Analysis and Recommendations

Stories Should be Done or Not-Done Within a Single Sprint

My questions is about splitting a story into versions. For example, we might have a story to allow a user to upload a file to a server. The first iteration of the story is usable by the customer but it's quick and dirty, the second adds file validation, the third version adds deltas, and so on.

The point is that these activities are probably too small to be a feature but too big to be a single story. The body of each story will contain all the acceptance criteria and other data, but what should that set of stories be named? Is it okay to say "User can upload file v1", "User can upload file v2", etc?

The way you're describing "splitting" user stories by versioning them is an anti-pattern. It implies that a user story (or, technically speaking, a Sprint Backlog item) maintains relevance beyond the time box of a single Sprint. While epics and themes may take multiple Sprints to fully deliver, a user story or Sprint Backlog item must be done or not-done within a single Sprint.

Tooling issues aside (and I do realize tools like JIRA can force people to think differently about what epics, features, and stories look like) the correct way to think about it is quite different. A "feature" is generally a coherent piece of user-facing functionality, which in your case would be something like:

As a Foo SaaS Server customer,
I want to be able to upload various types of files to the server
so that I can attach more than one attachment type to each ticket or blog post.

In this example, the user might want to be able to upload PDF files, Word documents, Excel spreadsheets, and UML diagrams. Assuming your system has to treat each type of file upload differently—an idea which I would challenge the Developers to reconsider, and perhaps ask the whole Scrum Team if it would make more sense to write a feature for treating all uploads the same instead—then it's okay to have more than one Product or Sprint Backlog item for each portion of the feature. However, according to the INVEST mnemonic and Scrum best practices, each user story should be small and testable, and as independent of the others as possible even though user stories can have prerequisites.

Sprints Should Have Sprint Goals

That said, a user story or other type of backlog item doesn't automatically cross Sprint boundaries. That means any work that's not-done at the end of each Sprint is future work on the Product Backlog that must be re-prioritized, re-estimated, and re-planned in a future Sprint.

The way you incorporate this fundamental fact into your workflow is to create a Sprint Goal each Sprint that contains a central coherence. For example, rather than trying to deliver the entire feature of "file upload support," it's okay to have multiple Sprints with Sprint Goals that deliver potentially-shippable increments of your feature. As an example, you might have three Sprints with Sprint Goals such as:

1. Support uploading and parsing PDF files into the user's widgets on the SaaS server.
2. Support uploading and parsing Word files into the user's widgets on the SaaS server.
3. Support uploading and parsing Excel files into the user's widgets on the SaaS server.

During each Sprint Planning event, the Developers would build a Sprint Backlog around Product Backlog items related to the current Sprint Goal. That way, the increment will be done or not-done at the end of each Sprint, and suitable for Sprint Review and (if properly sliced via INVEST) potentially-shippable as an incremental portion of the larger epic of supporting multiple upload types.

Backlog Items Don't Carry History

A Sprint is an ephemeral time box that gets filled with work items related to a single Sprint Goal. Once a Sprint is finished, it's gone forever; any unfinished work related to that Sprint is either discarded as no longer relevant, or placed back onto the Product Backlog for a future Sprint. In either case, the work done or not-done in the Sprint is not tracked as a first-class item within the system because all that matters is whether or not the Sprint Goal was met, and that only matters to the extent that it impacts the contents and ordering of the Product Backlog. In the end, the maintenance and delivery of goals defined within the Product Backlog has primacy.

For practical purposes, this means that Product Backlog items don't have "versions." They also don't carry metadata like effort-expended deltas, prior planning data that is frequently irrelevant to how to deliver the backlog item from a different starting point in a future Sprint, or other data that isn't directly related to prioritization or value. One could perhaps argue that a Product Backlog item could carry metadata such as:

1. Links to an epic or theme for the purposes of grouping or prioritizing on the Product Backlog.
2. Value estimates related to the specific item, or earned-value estimates related to the larger epic or theme.
3. Level-of-effort estimates to assist with prioritization and cost/benefit analysis that supports placing Product Backlog items into a sequential order.
4. Release plan estimates that target a particular release version or release date. NB: Just remember that release planning in Scrum and other agile frameworks is typically iteration-based rather than date- or effort-driven, and represents an estimate rather than a money-back guarantee.

but anything that smacks of carrying history forward from previous Sprints (such as treating incremental work as "story versioning") is likely a way to avoid true incremental or iterative planning based on vertical slicing and time-boxed delivery. In Scrum, all work each Sprint is new work, and must support the just-in-time prioritization and planning that the framework is designed for.

That means that the product itself is intended to be developed through emergent design, and that design may itself change at each inspect-and-adapt point. When you keep that in mind, you quickly realize that "feature versioning" as such is an anti-pattern that works against Scrum's underlying principles, especially since continuous product improvement is already baked into the framework. The type of versioning you describe doesn't provide self-contained, independent, or negotiable information about the related backlog items, and therefore works poorly from both a Product Backlog and a Sprint Backlog perspective.

How to Improve Your Scrum Implementation

Focus on the following, and the rest will take care of itself:

1. Treat product development as inherently incremental and iterative.
2. The Product Backlog should focus on what needs to be delivered to create value, and leave the implementation decisions (e.g. how the work is implemented) to Sprint Planning.
3. Use just-in-time planning as much as possible for the Product Backlog, and as a first-class approach to defining Sprint Goals and the Sprint Backlog.
4. Treat product architecture as an emergent design rather than relying on big, upfront planning.
5. Defer all design and implementation decisions until the last responsible moment.

Other techniques such as vertical splitting, INVEST, and test-first development all support these core principles, but it's the principles that matter most. If your process doesn't support the principles I laid out immediately above then it's time to reconsider the way Scrum is being implemented by the Scrum Team and identify how it can be streamlined and improved.