Staging the Backlog

The team and the Product Owner usually collaborates around the top of the backlog: around the "doable line" (as defined by the Definition of Ready), and the coming sprints (3 is a good number).

Even though we often envision the backlog as a refinery where large and fuzzy ideas gradually converts into doable User Stories, that is in reality never the case. This is because the items will never refine themselves, it is us that do it by working with one item at a time, dividing them into smaller pieces, answering specific questions, etc. The items will be refined in steps, or stages.

One of the benefits with the sprint-focused method of Scrum is that it defines very clearly one of the last of those stages: where features actually get implemented in usable code. Thanks to having a defined sprint-length, a Definition of Ready and a Definition of Done, we get a better overview of our actual capability to generate business value, and thus a better ability to plan within the scope of a couple of sprints. The well defined stage brings clarity.

There is a method to get that benefit and planning ability for larger scopes than sprints. The trick is to look at the backlog below the doable line and divide that into stages, just as Scrum defines the sprint stage, and try to define those other stages.

Cadences: Sprints and Features

A cadence is a rythm. Having retrospectives once in a month is a cadence, releasing software every third month is another, and sprint planning every second month is also a cadence. In By-The-Book-Scrum there is only one main cadence: the sprint, and everything (planning, demo, retro) is aligned to that (the other Scrum cadence being the 24-hour cycle between stand-up-meetings).

When adapting agile to your business, you often end up with a more polyrythmic approach. There can be weekly product-board meetings, retros every second sprint, releases every six sprints, and replanning of urgent items twice a week. That is completely in order and something that drives agility: the cadences will often reduce Mura and increase predictability, while still allowing for necessary variation.

Defining a stage before the sprint stage is about defining an outer cadence, a meaningful rythm that encompasses a number of sprints. The sprint is meaningful in that it is a time-frame large enough to implement a User Story in, but small enough for us to manage risk.

However, a single User Story in isolation won't be very useful to a real user. We need to group several User Stories into Features in order to realize real business value, something that a customer would be happy to actually pay us for.

So the next level of meaningful cadences, above the Sprint, would be the Feature Frame: The calendar time needed for our organization to realize something that the customer would pay us for.

Now, the time needed for us to realize a feature differs a lot. Some features are exactly one User Story, while others might span several. Being able to save in a certain format could be a selling-point targeting a whole new market segment, while the effort might equal a developer-tester-pair working together for three days. Other features, like a special mobile app of the GUI, might take whole teams working together for months to realize.

Small features aren't a problem. They fit into one User Story that will be realized in one particular sprint (or what you like to call your development cadences). It is everything that spans many sprints that pose a problem.

So the trick is to find a cadence that is large enough to cover the bulk (like 80%) of any new feature. An observation in many organizations is that most often, a feature will be realized within the timeframe of 6-12 weeks, with some tricky, but important features requiring double that time. Using sprints that are 2-4 weeks long, that would give us a meaningful cadence around 3 to 6 sprints.

The agile value "Measure progress in working software" where "working" is defined as "useful and in the hands of the user" implies that everything unreleased actually is waste, and that releases that consists of less than one feature is rather useless. Taken together, this would imply that there would potentially be 3 to 6 meaningful feature releases per year, each containing 1 or more features.

(Note that this reasoning doesn't imply that continuous releases is a bad thing. The actual release cycle might be much shorter than a sprint. Releasing improvements in your system nine times a day doesn't conflict with the idea of feature releases.)

So it would be a good idea to think of a Feature Stage in the backlog, before the Sprint Stage: each Feature Stage spanning 3 to 6 sprints. And if you have just a couple of releases of your software per year, think of aligning the releases containing the result of 1 to 3 Feature Stages (3-18 sprints of 2-4 weeks each, with a maximum of 52 weeks).

(In one organization I worked with, the Feature Stage was called a "Block" of 3-5 sprints with 1-2 blocks per release, 2-4 releases per year. In another organization, it was called an "Increment" and defined as 3-6 months worth of work.)

Precondition, Postcondition

When you have established one or two levels above the sprint (Feature/Release fx), you need to look into what would constitute the precondition and postcondition of those stages.

The postcondition is always determined by the following step. When the teams implement software, they need to state their Definition of Done so that the organization understands what is to be done in order to get the implemented increment released into the hands of the user. The Definition of Done must match the deployment organization.

The postcondition of the stage before the sprint should in the same manner match the precondition of the Sprint Stage, ie the Definition of Ready of the teams, or the "doable"-line as I like to call it.

If you use the 3-sprints-ahead method for grooming User Stories, you could have a postcondition of a feature-stage stating that you are done with your analysis when the feature is broken down so it will be fixable within 3 sprints. A precondition for could be that the user, the main use-case, and the business values are clearly defined. Given that, a group of architects and business analysts could collaborate into breaking the feature down into doable sub-goals at the User Story level.

The level above the feature could be a vision increasing the business value for a whole market segment. Here the precondition could be the vision, and the postcondition a number of features described as use-cases (or happy-path User Stories), that the Feature Stage could work with.

As always: your mileage may vary, and you need to find your own stages by considering what a reasonable cadences, post- and preconditions you have in your organization. The important realization is that you need to think through the stages you need for the transition from idea into executable business value.