Hierarchial Requirements and Scrum

As the Product Owner of ScrumWorks, I’m often asked why ScrumWorks does not support hierarchical nesting of backlog items (i.e., user stories, PBIs, etc.).  The answer is simple but highlights some profound differences in the way requirements are managed in Scrum and Agile as opposed to other methods.

The short answer is prioritization.  Scrum is predicated on the fact that all work is listed in a linear, one-dimensional list and prioritized relative to other items on that list (see Agile Software Development with Scrum for more on the Product Backlog).  The relative priority of items is always clear and there are no confusing situations like two backlog items with the same priority (e.g., #1!) that both need to be done (e.g., now!).  Rather, the Product Owner has the hard job of distinguishing which items are more important than others.

So why can’t backlog items be organized into tree-like hierarchies?  You can easily prioritize the top level item, but often the top-level of the hierarchy represents a large amount of effort.  So much so that the item itself may span sprints or even several releases.  So how does one prioritize such a large item that will be done over several sprints and possibility as part of several releases?  The problem is that your hierarchy actually contains individual backlog items with differing priorities.  Some might be done in the first few sprints, while others are not as important (gold-plating) and might be done in a later sprint or even a later version of the product.  The hierarchy is obscuring the true priority of the individual items.

There is a second reason why taking a hierarchical approach to requirements is less desirable in Scrum: it encourages product owners/managers to prematurely define detailed requirements.  With a hierarchical system, the Product Owner is encouraged to break work down into very granular detail far before the feature defined in the requirement is needed in the product.  This is counter to the lean principle that suggests a just-in-time approach to requirements that encourages product owners to define the real requirements when they are needed just in time for a sprint.

Scrum and Agile propose a new paradigm: use large high-level backlog items (often called epics) and peel off smaller items from that large Epic as the need arises and priority demands.  Pretty soon, your epic dissolves (in terms of effort points) because it is split off into many smaller items.  This is why CSM courses teach that you not split your backlog items into very granular items until they become a priority for the product.  You will have an unwieldy backlog.  Not to mention, this is not very agile/lean: you’re spending a lot of time and effort detailing requirements you may never actually need or build.  Instead, keep distant, low priority items as large “epics” so that your backlog remains manageable.

How does ScrumWorks handle categorization?  Themes represent a free tagging system that allows users to apply keywords, or Themes, to individual backlog items.  Themes are meant to keep the association between split off items and the original epic.  Simply theme all split off items to keep them related.  In the future, we’re considering building a split-history/traceability function that shows how a particular epic was split over time, the relationship of the splits, when items were created, finished, deleted, etc.  I’ve attached a mock-up (login required) of what the report might look like.  But in essence this report provides a roll up of how a requirement evolved and it’s current status.

Traceability_SH_1.png36.27 KB

Download the PDF version: Hierarchical Requirements and Scrum blog

Victor Szalvay

Victor Szalvay currently leads product development for CollabNet’s ScrumWorks® product suite. In that capacity, he works closely with customers, stakeholders, and the development teams to deliver high business value each release cycle. With more than 150,000 active users worldwide, ScrumWorks is used by more than half of the Fortune 100 and boasts the largest market share of any Agile management tool.

Posted in Agile
3 comments on “Hierarchial Requirements and Scrum
  1. Gregory Smith says:

    Hi Nick;

    We too have a large effort where most teams are using scrum. We have a combination of code and content developers aligned into 10 Scrum teams. Much of the functionality we deliver requires coordination across teams and departments. We had Jeff Sutherland come and do some initial ramp up training when we only had 2-3 teams but our efforts have become bigger and more complex. We are struggling with nearly the same array of SOS issues that you call out.

    We are experimenting with allowing 1 team with a dedicated PO to be ‘point’ and having that team in turn act as the PO for constituent teams. This simplifies the points of contact for stakeholders and ensures that constituent teams are delivering needed dependencies to the ‘point’ team in a sort of hybrid model somewhere between scrum and classic release management. I do not think we have it quite perfected yet but it has been a good excercise and I am liking the over-all direction.

    I find it unacceptable for a PO to need to keep track of multiple overlapping teams/sprints and attempt to coordinate the deliveries of multiple teams into cohesive features. It causes additional communications overhead and invites the PO to manage “aka meddle with” team and inter-team dependencies that they should be managing themselves. As a result we’re putting together a hierarchical system allowing a high level ticket to be decomposed into sprint backlog items across several teams while maintaining progress/burndown feeders back into the master ticket.

    Do you keep an independent blog or any kind of a chronicle of your particular adventures? I am interested in hearing more about the methods you are finding success with.

    -G

  2. Michael James says:

    This opens about 10 different threads which could all lead to interesting discussions. I’ve been investigating approaches large organizations apply to these challenges and hope to publish my recommendations soon.

    Regarding Vic’s original point, we feel hierarchies can be useful ways of thinking about requirements but you also need to break free of them when it comes to prioritization. The ScrumWorks theme tagging mechanism allows you to retain those hierarchies even as you reach deep inside them for the juicy (high ROI) bits you need to do right now.

    We need a 1-dimensional prioritized transformation when it comes to *scheduling work*. Our ability to apply multiple tags means you can apply as many groupings as you find useful for the complexity of your problem, whether that’s a Work Breakdown Structure, a traceback of split epics (megastories) and goals, or a traditional numbered requirements document.

    Michael James
    Software Process Consultant (who spent years doing aircraft/spacecraft real-time embedded systems thus can appreciate Nick’s challenges)
    http://www.danube.com

  3. Michael James says:

    With the 2.1.0 release, ScrumWorks Pro now allows both n-dimensional groupings (via themes) and more conventional nested hierarchies (via Programs and Groups). Some of our customers have already seized this feature to organize their large backlogs.

    I see the need for this even with the relatively simple backlog students create during the CSM courses. Often they’ll need to spread Post-It notes across the wall in messy groups and tables before they can cherry pick the highest ROI items as candidates for the first Sprint Backlogs.

    No one said being a Product Owner was easy. But the analytics in ScrumWorks Pro can ease the pain in large high-stakes projects.

    –mj

Leave a Reply

Your email address will not be published. Required fields are marked *

*