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

  • 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?

  • 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.

Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2