How can we prevent business value from being dependent on multiple user stories in Scrum?

Question

Our dev team keeps finding ourselves in a scenario where we have multiple stories, none of which actually provide usable value by themselves. In order to deliver any real world value, we need to complete a bunch of them together. If grouped together into larger stories, they are too large and unpredictable, and if any of them remains unfinished we cannot deploy the lot.

Simple Example

The user needs to be able to log in to an account section of the website, to see their orders and manage their profile.

We would attempt to break this down into small stories which focus on one piece of functionality each. Maybe something like this, with example sizes:

• As a user I can log in (2)
• As a user I can log out (1)
• As a user I can view a list of my orders (3)
• As a user I can view my personal profile (2)
• As a user I can edit my personal profile (2)

We could deliver just the login functionality, but without an account section to actually log in to, what's the point? Similarly, what's the point of having a login without a logout function? So should we then have one large story which involves logging in, logging out, and viewing the list of orders? In such a case, the size probably becomes 8 points. We have found that stories over 5pt don't work well for us and often derail the sprint because the estimate was inaccurate.

If we finish the sprint and you cannot view a list of orders yet, most of the other stories are sort of useless until the end of the next sprint when those are finished. This then doubles the amount of time (2 sprints) until we can actually deliver some value to the client.

Another issue here is we don't know where to include the effort required to build the "account" section itself. It needs a general page design, maybe a menu, at minimum. In order to view a list of orders, we need some sort of account page/section designed and built as well. Where should that work be included? It doesn't seem right to me to have a "build account section" story, which doesn't actually have anything other than a blank page with a menu, let's say.

If we were to for some reason add the "build account section" work into the "view orders" story, how does one then complete the "view personal profile" story, which also needs that account section built?

How should we write stories which cover the requirements? How do we eliminate the dependencies they have on each other?

Answer 1

Think "Release" Instead of Stories to Track Value

User stories are not meant to be a measure of business value. As a rule of thumb, each Sprint should deliver a potentially-releasable increment of product, but nothing requires that each iteration deliver X amount of value. User stories just represent INVEST-sized units of work that collectively deliver the elements of the product that the Product Owner (and by extension the stakeholders) think will provide value.

In Scrum, product value is generally found in the incremental delivery of Sprint Goals. Every Sprint should have a goal, and that goal usually represents a unit of overall product value. That unit may be standalone, or it may be part of a larger theme or epic that won't be marketable until complete. The product must always be in a potentially-shippable state at the end of each Sprint, but that doesn't mean every Sprint must ship an edition of the product or that multi-Sprint release planning isn't an essential activity for the Product Owner.

From your post, it looks like your Sprints lack the central coherence of a Sprint Goal to express the organizational value of each iteration. This is required by the Scrum framework.

Furthermore, your agile implementation may have skipped an Agile Release Plan that expresses the aggregate value or fitness-for-purpose of specific product milestones. While not explicitly a feature of the Scrum framework, agile release planning is incorporated into the Product Owner role. As the Product Owner, it's your job to apply your product vision and the Development Team's expertise to the Product Backlog, and determine how many features are needed (and how many Sprints it will likely take to deliver those necessary features) in order to release a useful/salable version of the product under development.

Some products can release in very small increments. Cloud-native software is one such example. Other products require significantly more value to make a compelling release. For example, no one would release a whole new edition of an encyclopedia after changing a single section. How big or featureful a release needs to be for your product will depend on the product, your industry, and your market. Your mileage can therefore vary greatly.

Answer 2

The short answer is that there are many different cases where delivering a complete, market-ready segment of functionality is not reasonable in one sprint. So, let's start with the simple answer: each of those things you list is valuable to the customer and you could make it "potentially shippable" in the sense that it is technologically and quality-wise sound, even if it doesn't make business sense to ship it. Therefor, creating just:

As an account holder, I would like my account to be secured so other people can't see my personal info.

and not have anything behind that yet - or you could also do:

As an account holder, I would like to view my list of orders so I can follow up on them.

without a login. Both are independently valuable even if you wouldn't actually release them to a wider audience.

That said, I would not immediately resign myself to that. A lot of times, these things are larger because we are thinking about what a full implementation would look like. Do you plan on incorporating things like google or facebook signon into your process in addition to your own login system? Often times only offering those at first provide an easier small slice of the login feature. Alternatively, I've developed login features where I had to manually add the user into the system and the only thing I created for the first pass was the code that authenticated a login. That was only maybe 20% of the total work for the whole login feature.

Similarly, you might be able to shrink the order viewer. Are there parts that are easier to do than others? If I think about Amazon's order viewing, I would definitely chop out any updating or tracking for the first pass. Could just an order number and status provide initial value to start?

There is no "right" way to do this because every case is different, but sometimes we find very interesting ways to break stories up when we look at capabilities (I can log in) instead of components (the login feature) and when we look at different customer segments (a user using SSO).

Answer 3

Tying into Daniel's answer, several Agile methods allow for aggregating stories into a larger story some call an "epic" that describes a larger deliverable like a feature. Each sprint does deliver a "potentially releasable" outcome--a variant on Daniel's phrase--like the "account section" you describe. And there often is value in showing that to the customer (or customer's rep, like the Product Owner in Scrum) even in that form, because getting a minor course correction at that point prevents a larger one down the road. But as he says, for business reasons you may not yet release it to the customer.

This approach allows a team to work on multiple epics (features) each sprint. If there are dependencies in series, completing the required epic first while also working on sprint-completable chunks (stories) of the other epic gets you closer to the released product. As Daniel says, smaller bits of functionality is the key to making that work.

Answer 4

I would go with the approach - that has been highly appreciated by our professors, of having a simple user story which is split into multiple task. For example take a user login use case. User story : As a user I would like to login into my account.(This gives really high level view of a user story) Splitting it into multiple dependent tasks like: 1) Set-up a user database - 2 story points 2) Create a front-end - 3 story points 3) User login API - 3 story points 4) Third party integration for login like google, linkedin etc - 5 story points therefore the total story point for this user story comes up to 13 points. This way it's easy to track the dependencies and progress of the user story.

I hope this was helpful :)