3

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?

4
  • 1
    Sometimes stories can't be sliced any finer without losing value. But in this case, maybe there is a predefined model that users can apply to a picture? Then you don't need the model creation UI yet (or maybe at all, depending on how people feel about the presets). – jonrsharpe Nov 13 '19 at 9:26
  • Why do you say stories like "I want to upload my image" aren't valuable? That seems like a critical part of the overall project. That sort of story seems to have an extremely high value. Same with being able to draw a zone and delete a zone. – Bryan Oakley Nov 13 '19 at 9:45
  • @BryanOakley I wanted to say by "upload an image" is maybe valuable but the two others wouldn't be if this one is not implemented (so they are not independant anymore) – Amanite Laurine Nov 13 '19 at 9:48
  • @jonrsharpe that's a great idea ! (I wouldn't be able to implement it on my project because it is really hard to find a default model that would suit to any client, but in other circumstances, it would have work) – Amanite Laurine Nov 13 '19 at 9:50
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.

1
  • Thanks a lot for your complete response =) It seems clearer to me now – Amanite Laurine Nov 13 '19 at 15:47
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.

8
  • Thanks for your response ! Actually I was always told that a story must still have a user value and something like "create a database" is more a "Product Backlog Items" that can be integrated to a sprint but is not a user story – Amanite Laurine Nov 13 '19 at 10:08
  • "I was always told that a story must still have a user value" - yes, a story must ultimately provide value to the user, but that doesn't mean it has to be a user-visible feature. Having a database to store the images is extremely valuable, for example. They may not care that it's a database versus a folder of images, but they will care that the images can be saved and retrieved. – Bryan Oakley Nov 13 '19 at 10:11
  • "something like "create a database" is more a "Product Backlog Items" that can be integrated to a sprint but is not a user story" - not all stories are user stories. User stories are good for defining what the product does from a user's perspective, but your project will have many other stories that benefit the user but which don't directly translate into a user visible feature. – Bryan Oakley Nov 13 '19 at 10:13
  • So are "Product Backlog Items" and "stories" the same thing? – Amanite Laurine Nov 13 '19 at 10:20
  • 3
    I have to disagree as well about creating a database table being a valid user story. It should be a dev task. There is also nothing wrong with designing just a thin slice of functionality to begin with. The table might start out with a primary key, audit columns and a BLOB to hold the image data (or UUID to hold the Id of an image in an external service). This should be easy to implement. Uploading the image and all the checks that go along with it are additional user stories, including the actual "upload and save" action. – Greg Burghardt Nov 13 '19 at 11:32
2

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"1 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.


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

11
  • What I am saying is, in my case, there is no way to achieve their goal (even if the UI is ugly to gain times) without the whole functionnality that doesn't fit in one sprint – Amanite Laurine Nov 13 '19 at 11:39
  • @AmaniteLaurine How do you know, did you capture the value? If you didn't, for all you know, maybe a good MVP for them is to save the images & models locally, and then put them manually on a network share. (Again, making it up; the point is, they can come up with workarounds until you come up with the next version.) Even if this is not the case, as I've said, don't get too caught up in the formalism - find something to work on and simplify or alter the problem so that it's manageable. – Filip Milovanović Nov 13 '19 at 12:02
  • @AmaniteLaurine You said "The first one needs to [...] be saved on the server, CRUD zones on this image, save the zones..." - well, mock the server, ignore the database and save to a local file. Work on the core functionality, and add that stuff later (keep in mind that you are going to be storing & loading data to & from a remote source, though - this has implications for access patterns and abstractions you use). Doing it that way may even give you some extra insight, so that you don't, say, lock yourself into an early database design that was maybe based on limited information, etc. – Filip Milovanović Nov 13 '19 at 12:02
  • @AmaniteLaurine P.S. Found this online - it illustrates how to go about building an MVP (minimum viable product). The way you are thinking now is, you trying to build a car, but you are starting with a wheel. Don't build a wheel, find a way to build a skateboard. – Filip Milovanović Nov 13 '19 at 12:14
  • 1
    @AmaniteLaurine BTW, if you can't, for whatever reason, have this kind of dynamic with the business on this particular project, then following Scrum practices is, IMO, more or less just going through the motions, without getting enough of the benefits they are supposed to provide, so there's no too much point to trying to follow them "the right way" - in that case, I would focus on finding things that you can practically do to get the development going, weather they fit into the Scrum formalism or not. – Filip Milovanović Nov 13 '19 at 14:25
1

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.

8
  • If I understand it well, "independent" means echnically independent and not functionnally independent ? – Amanite Laurine Nov 13 '19 at 9:51
  • Why would they not be able to demo the back-end story? The point of the demo isn't to showcase completed features, it's to showcase work that was done. Having a slide that says "we created a database with X tables, and API functions to update the database" is a sufficient demo. – Bryan Oakley Nov 13 '19 at 9:59
  • How is a story that focuses on technical aspects not valuable? If they have to be done for the project to succeed, they are valuable. Customers can benefit from refactorings if it makes the product easier to support or more efficient. – Bryan Oakley Nov 13 '19 at 10:01
  • @AmaniteLaurine: You want to think of how you can incrementally deliver pieces of a large product. If you consider the pieces as "dependent" simply because they are part of the same product, then you'd had to deliver the whole product in one go, which effectively turns into waterfall. – casablanca Nov 13 '19 at 10:12
  • 2
    @AmaniteLaurine: I see what you mean, yes, the stories have dependencies on each other, and that may affect how you prioritize your backlog. But beyond that, "independent" simply means that each story is able to independently deliver some value. – casablanca Nov 13 '19 at 10:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.