How can a user story be independent, small AND valuable with big functionalities?

Question

How can a user story be independent and small (following INVEST acronym)? Most of the time we have big functionalities that depends on each other.

As an example, we made an interface for users where they can define zones on a picture (this zone list of zones is called a "model"). For each zone, user can define a folder. The goal is, when a user uploads another picture, they can select a model, and the software extracts the content of the zones on the uploaded image as new small images (like a picture cutter). Each "sub-image" is placed in the folder corresponding to the zone.

If I try to make user stories on this functionality, either they will be long or either they won't be independent.

I can try this:

• As an administrator, I want to define zones on an example picture to save a "model".
• As a user, I want to split my picture in other small pictures corresponding to my model.

These stories will be very long. The first one needs to develop an interface where the user can send an image, be saved on the server, CRUD zones on this image, save the zones... this will cost a lot of time! And they are not valuable; defining a zone for itself is useless if I don't develop the part where the software uses zones.

And if I do it like this:

• As an admin, I want to upload my image to draw zones on it
• As an admin, I want to draw a zone on my image to define it
• As an admin, I want to delete my zone...

Now the US are small but they are not independent anymore (and still not valuable)

I tried that too:

• as a user, I want to define a model and upload an image that correspond it so I can extract small images from a big one

Now I have one big user story that is independent from other functionalities we would develop, this is valuable, but it is awfully long.

Which task cutting would be the best one? Is it one of these three or something else? Have I missed something about the INVEST acronym?

Answer 1

(I went to bed wholly unsatisfied with my first answer, so I'm writing this second answer to attack the question from a different perspective)

How can a user story be independent, small AND valuable with big functionalities?

It can't. A user story should not have big functionalities, that's what epics are for. Stories should be independent, valuable, and with small functionalities.

Have I missed something about the INVEST acronym?

Yes, I think you're taking the words independent and valuable a bit too literally.

Value

Value isn't necessarily defined as meaning the user can start using it right away. It means that it ultimately has value to the user, even if that value can't be realized when the story is complete. The value is that it moves you a step closer to your goal. It's a necessary part of the final solution, so it has inherent value.

For example, a story for creating a database schema is small and independent, and it's also incredibly valuable. It's not valuable to the end-user per se -- you can't deliver it to them and they can't start using it -- but it's extremely valuable nonetheless. You can still deliver it (read: consider it done) without the user being able to immediately start using it.

Independence

The reality is, no story will ever be completely independent. Software is nothing but a collection of interdependent, connected components (functions, classes, services, databases, etc). In this context, "independent" doesn't mean that the story or feature itself is literally self-contained and can stand alone. Rather, it means that it can be developed independently from other stories.

For example, it seems that creating an API to retrieve an image from a database is dependent on the database. It's not, however, since the database can be mocked out during development.

Likewise, it seems that being able to draw a zone on an image requires an image. It does, but it doesn't require that stories related to images be completed. During development of the "draw a zone" story, a mock image can be used. The final feature may depend on many other stories, but the development of the story can be done independently of other stories.

Small

Small is the one word that can be taken literally. I think no matter which scrum book or seminar you learned from, or which consultant is leading you, or who your scrummaster is, everyone agrees a story needs to fit inside of a single sprint. That is a fundamental aspect of scrum - you need to break the work down into small units of work because science tells us that the bigger the unit of work, the less accurate the estimation will be. Plus, there are psychological benefits from completing chunks of work on a regular cadence.

What I personally find best is to stop thinking of stories as user stories and instead think of them as just stories (or what some teams call product backlog items). Some will be traditional user stories, but there is plenty of other work that needs to be done which the user will never see or know about (think databases, web server infrastructure, etc). Even though they won't ever see it or know about it, they will see the effects of it (eg: the fact that their work is saved on a server), and that is valuable.

Scrum is a collection of guidelines, not rules

Don't get too hung up on the dogma. Scrum isn't a strict set of rules, it is a set of guidelines. The goal is to break your work up into small manageable chunks that the team can work on in a logical order. It doesn't really matter if you call them user stories, stories, product backlog items, or anything else. The goal is to identify what you're building and why you're building it, and to break it down into the smallest parts possible so that you can do better and more reliable estimations.

Answer 2

I think part of the problem is your misunderstanding of the term 'valuable'. Even just the smallest piece of the overall project is valuable. For example, a story to create a database table to hold the images is valuable. It's not valuable all by itself (ie: a user can't immediately use it), but it's valuable -- invaluable -- to the project itself.

As for being independent, that's a good goal but it isn't a strict requirement. Some interdependence is simply unavoidable -- you can't show a list of items unless you've got a list of items, you can't create zones if you don't have an image, you can't log in if you don't have a website, etc.

Remember, agile isn't a strict set of rules, it's a set of guiding principles.

These stories will be very long, The first one needs to develop an interface where the user can send an image, be saved on the server, CRUD zones on this image, save the zones... this will cost a lot of time!

Your stories are way too big. A story needs to be something that can be accomplished in less than a sprint. In your case, each of the items in the above quote would make for an individual story (or multiple stories).

For example, your epic is something like "need to be able to upload an image". Roughly speaking, the stories might be for creating all of the following:

• database tables for saving uploaded images
• infrastructure for storing these images in the cloud
• an API for saving an image in the database
• an API for updating an image in the database
• an API for deleting an image in the database
• an API for retrieving an image in the database
• a UI for uploading an image
• a UI for viewing a list of uploaded images
• a UI for selecting an image for deletion
• a UI for updating an image

... and if you don't even have a website, then you will need stories to create a landing page, a login page, perhaps a dashboard, and so on.

A story shouldn't be a complete user-visible feature. A story is one bullet point in a long list of things you need to do in order to deliver a product.

The way I think of it is this: the first thing your team should do is sit down and brainstorm on all the things that have to happen in order to deliver the product. Include everything - creating each table, creating each piece of the website, creating APIs, etc. You should end up with a rather large bulleted list.

Almost every bullet item on that list then becomes a story, or possibly a task on a story. Each one will be small, and each one will be valuable to the project as a whole. After all, you can't mark up an image until you upload it, there's no point in marking it up if you can't save it, and so on.

Answer 3

First, don't get too invested in following the formalism to the tee, it's more important to capture the the needs of the business and get on with the work then to obsess with how exactly it should be done.

That said, the user story format is:

As a <user in some business role>
I want <to do something>
so that <I can get some business value>.

The reason is that you want to understand what they are actually after, rather then just accept a specification from them; the idea is that you are there to provide your expertise and solve a problem for them, not to execute a set of instructions. You want to find out why the user wants that something done in a wider context of their business goals - so that you can build the right thing.

When it comes to value, you have to think in terms of the bussines/domain value it provides for the user. Also, don't think about the user role as some generic role defined by the system, or a job title, but rather think in terms of what it means in the context of the business (or whatever the endeavor in question).

So,

As an administrator (what does that role actually entail?),
I want to define a model
(if you all understand what a "model" is in this context,
you don't need to go into more detail than that; describe intent, not the feature)
so that (what?).

The "what" (value) part could be something like: my subordinates can proceed with their work. Now, I'm making that up, of course, and it's probably not a best example of a "business value". But maybe it is; maybe their business currently has a bottleneck when it comes to producing these models, and the employees are mostly sitting around waiting, so they see business value in removing this bottleneck? Again, I'm making this up, but, it is important to obtain this information. However, you can't guess this - you have to talk to your customers / domain experts (users or their bosses), and ask them what the value is (and maybe you'll need to steer the conversation a bit in order to extract this information - ask a lot of "why" questions).

Next, the "independence" bit: stories should be independent enough so that you can move them up and down the priority queue; so don't think "independent in functionality", but rather can you work independently on them following your usual development practices that let you do cool things like use mock data, fake services, etc.

Finally, what does "small" mean?
Small enough to be confident that it can be done within a couple of days, or maybe a week, using the simplest approach possible. Something that will let the user achieve their goal in the simplest way; it may be just the bare bone features, and it may look ugly, but the goal is to be usable so that they can get their value from it. And if you didn't capture what's the value in the story, you can't be sure that you are delivering it.

And, yes, it may take some time, but it shouldn't take, like, a month - if it looks like it might, split it into smaller independent peaces of work (you don't have to do them all in the same sprint - that's something to negotiate).

Note that once you have the initial stories captured so that you have a good understanding of the business needs, as you are dealing with the backlog over time, you can refine them, split and negotiate them as the need arises according to whatever organizational strategy your team uses within the process.

Because you have captured the value and because you are expanding your understanding of the domain constantly, and because you have access to domain experts, you (your team) are the one(s) who are in the best position to make decisions about what is the best way to do all these things, in a way that delivers the most value to the business, and the most important value first (so that if they decide to wrap up the project at some point, they get their most important business needs met). Except for general advice, nobody can really make these decisions but you (the team), and if you can't, then either go "pester"¹ the domain experts until you have enough understanding so that you can, or build something small, get feedback, and learn from it for the next round (or do both).

Once you commit to a story and start getting into technical details, drop the story format; the story is there to provide context.

---

¹ Don't really pester them; you want them to be cooperative :)

Answer 4

If you ever feel like a story is too long, I would err on the side of breaking it into smaller stories. Over time, your team will develop a feel for what the "right size" is, and this will vary based on your specific product and the length of your sprints.

• As an admin, I want to upload my image to draw zones on it
• As an admin, I want to draw a zone on my image to define it
• As an admin, I want to delete my zone...

Now the US are small but they are not independent anymore (and still not valuable)

This seems like a perfectly reasonable way to split the stories. I would argue that they are independent and valuable because each story delivers an incremental piece (however small) of the overall product that can be immediately demoed / tested. You can get feedback from the customer for each story and course-correct as necessary. If you attempt to build a large chunk of functionality in a single story, it becomes harder to track progress and you lose the benefit of continuous customer feedback.

An example of something that is not independent would be building the back-end first and then separately building the UI later. By doing this, you would be splitting a single customer requirement across multiple stories and you likely won't be able to demo just the back-end story.

An example of something that is not valuable would be creating a story that focuses on technical aspects, refactoring or implementation details without mention of how the customer is benefited.