# Is it better to deliver many low-value stories or few high-value stories?

I'm unfamiliar with Agile/Scrum (not sure which is the right term here), and I have what seems like a very basic question, but I can't seem to find an answer online.

Here is an exaggerated hypothetical to illustrate my problem:

Let's say my sprint has only enough capacity to fit in either 1 big, high priority story (let's say the priority/value is 5) or 10 smaller, low priority stories (priority/value of each is 1).

Mathematically, it seems like I should choose to fill my sprint with the lower priority stories, since that delivers `10 x 1 = 10` units of 'value' to the customer, as opposed to just `1 x 5 = 5` units.

However, intuitively, I don't think the customer would be pleased with that. From their perspective, I feel like they wouldn't care that the 'total' value delivered was higher -- all they'd see is that their most important story wasn't done, but a bunch of less important stories (that they might have been okay with not being done?) were done instead.

So, which of these two perspectives is correct:
- Deliver as much 'total value' as possible even if each individual story isn't the most important
or
- Deliver as many of the most important (highest value) items as possible, even if the 'total value' at the end is lesser than in the first option

You've encountered two important facts about planning:

1) Priority and value are not the same thing. You have a number next to each story. If those numbers do not have the property that 10 stories with the number 1 next to them are worth more than 1 story with the number 5 next to it, then the number next to each story does not represent value, at least not on an arithmetic scale. In which case don't call it "value". If those numbers do not have the property that greatest value is achieved by working on the story with the biggest[*] number first, then the number next to each story does not represent priority. In which case don't call it "priority". Unless the numbers somehow contrive to have both properties at once, don't call them "priority/value".

2) The numbers are only vague approximations anyway. Also, depending where the numbers came from, things might have changed since the time when someone wrote a number next to the story. So any process that just crunches the numbers will sometimes not give you the right answer.

You want to do the thing with highest value to the customer, which is fine. Your instinct in a particular case might that the 5-point story would have higher value to the customer than all 10 1-point stories. That is to say, your instinct is that the numbers you have really do represent priority, not value. That's also fine. If you're doing Agile then you have direct access to the customer pretty much at all times[**], so you can easily check whether your instinct matches that of your customer. You can also check with the rest of your team. If so then proceed with what you collectively believe to be highest value.

There are circumstances where the customer would prefer the 10 small fixes over the one big fix. For example this would happen when many of the small things are annoying on a day-to-day basis, while the big thing is a new feature that will be lovely when it lands, but everyone is getting on without it. Then you would do a sprint designed to improve general quality of life rather than to deliver "the next feature".

But, whichever is the "right answer", if the numbers written next to the stories don't give you the right answer, then they don't represent what they claim to represent, and you should not kid yourself, your team, or the client, that this is what they represent. You can't do good work by blindly following bad numbers. So, either write down better numbers or else pay only very loose attention to the numbers and do what you all agree is right.

[*] or smallest, if priority 1 is the most prioritous!

[**] this is the logical contrapositive to the statement, "if you can't check in with the client then you aren't doing Agile, so don't kid yourself you are". The "client" here might be some stand-in for the actual fee-paying customer, especially for software that has a very large number of paying customers. But if you can't talk to at least a nominal customer then you're not agile.

• It might be useful to introduce the urgent / important matrix as replacements for priority and value. Jul 22 '19 at 14:05
• @mattdm: indeed, or consider that "urgency" loosly speaking describes the behaviour of value as a function of time. A story with high urgency is a story whose value will drop significantly (perhaps even to 0) at some point in the fairly near future. If you know what point in the future that is, you have a deadline to plan to. Jul 22 '19 at 14:12
• The way I sometimes put this, when on suffuciently jovial terms with the client, is "what is the deadline for this, by which I mean what is the date where if I can't do it by that date, I should not do it at all"? Jul 22 '19 at 14:21
• Wow, I never thought of this but, in retrospect, this really does explain my conflicting intuitions -- intuition #1 makes sense if the no. represents value, while intuition #2 makes sense if it represents priority. I kept vacillating between the two intuitions because I kept trying to reconcile the number as representing both value and priority in my mind. Thanks a lot Steve, as well as everyone else!
– Seth
Jul 23 '19 at 0:58

You do the stories at the top of the backlog first. It doesn't matter if they are a 5 or a 1 or whatever. A product owner that has done his or her job properly will have the backlog ordered by what brings the most value to the users and/or client. By value one understands usefulness for users, market advantage for the client, making more money, shipping more products, adopting more puppies, whatever it is.

If it's in the top of the backlog then that's needed next. The product owner has had the proper conversations with the client and decided that this or that are the next things the team should work on.

If it's lower in the backlog then that means it can wait a while while some items at the bottom of the backlog might never be done.

The idea is not to jam your sprint with whatever fits best, or whatever looks like the team achieved more, but to take into the sprint whatever the team needs to work on next.

In Scrum/Agile, the client can stop the project at any time. They can say "the product does everything I need. The rest of stories we could have or are nice to have, but not critical". Let's stop here. Thank you. Now imagine the client wants to do the same but you didn't work on the story of 5 which was more valuable but instead worked on a bunch of 1s. They now need another sprint or two for the team to add what's missing to the product.

Do you have an ordered backlog or not? The stories with 1 do you pick from various places withing the backlog just because they happen to be 1 and you can fit more in the sprint or are they at the top of the backlog? Is the 5 story at the top of the backlog?

Product owner together with the client decide on what you need to work next. You don't do it mathematically by `1 x 5` or `10 x 1`, or intuitively because it feels you are achieving more. Product owner together with the client decide. The team just tells them what they can actually achieve into the sprint. There might be some negotiation if, technically, some stories make more sense to be done first or in a certain order, but you always work from the top of the backlog.

If the numbers you have next to stories actually reflect the value they provide to the users/client, then the stories will be at the top of the backlog, in which case the numbers next to them become redundant.

• "Do you have an ordered backlog or not?" FWIW, my interpretation of the question was that the questioner is trying to order the backlog (or at least to identify the top of it in order to make a sprint), based on these initial numbers. So another key question to ask would be, "where did the numbers come from, and what did the person who made them up think they mean?". If they came from the customer and the customer thinks they represent priority, then your backlog is ordered and you're finished :-) Jul 24 '19 at 14:52

Great question - people frequently ask similar things like this: in a big backlog of items, does it matter which I do - and it does. In fact, it might be the most important part of scrum.

The key is that each sprint, scrum asks the team to create a potentially shippable increment of the product. This can be a confusing term but for this question, let's just say that some real user in a customer group can potentially use the changes in some environment.

If the team is doing this, then part of planning is answering the question "What would be the most valuable next increment?" This can be many type of value including actual customer features, knowledge value, risk mitigation, etc. Answering this will tell you which backlog items are most important to work on. Some sprints it will be a few bigger ones. Other sprints will be many small ones.

As with so many things in agile, the answer is to "ask the team".

There is no right or wrong answer as every situation and domain varies. To follow agile you do not need to always pick one or the other approach, but you do need to have the conversation with the right people.

In the real world, I can imagine a conversation such as this:

Team: "We have the capacity this sprint to deliver a large, high-value story or many smaller stories. Our preference is for smaller stories as they make it easier for us to manage the sprint. What are your thoughts Product Owner?"

Product Owner: I appreciate that it is easier and probably more productive for you to work on the smaller stories, but in this case it is very important to my stakeholders to get that high-value story in place. Could we focus on that please?

Team: Understood.

• Is this "ask the team" or "ask the product owner"? Jul 22 '19 at 14:02
• @mattdm: ideally the product owner is deemed to be part of the team, so the conversation above is actually between the product owner and the rest of the team. Jul 22 '19 at 14:26
• It is a conversation between the development team and the Product Owner. The development team can give input about the impact of story size and other technical matters, while the Product Owner brings their knowledge of the product and the stakeholders. Jul 22 '19 at 14:51

It is better to maximize value delivered in a Sprint, so whatever mixture of stories does this in the Sprint is better.

An approach is to have stakeholders / PO assign a value to stories, and the Team assign effort. Your velocity is how much effort you deliver each Sprint.

Manage your Backlog and Sprint stories based on delivering maximum value per Sprint.

This is not a substitute for talking to people. But it can guide the Backlog-grooming and increase focus on "low hanging fruit" by deferring focus on high-effort, low-value stories until later.

Usually, stakeholders adjust the initial value to make the Backlog fit what they want it to be - and that is OK. The discussion about the "real value" of stories is often useful and can refine stories to what really has value. Once stakeholders see Sprints delivering stories, they stop worrying so much if their story is in this or the next Sprint (until a deadline approaches).

Note that value and effort (Story Points?) can be unit-less, and often benefit from being so, as long as they are proportionate between stories. This removes many pointless arguments of time and money when trying to rank stories for the Backlog. I like the semi-Fibonacci sequence of 1,2,3,5,10,20,30,50,100 to avoid people wasting time estimating things that are too big and fuzzy to be accurate anyway (but if someone really wants a value or effort of 45, who cares?).

I would recommend that you look into Lean Value Tree. It has helped our teams tremendously with making sure we deliver that right products to meet the strategy of the organisation.