More on the Agile Release Train – Internal vs External Releases

In a number of posts, including Enterprise Agility – The Big Picture(5) The Release Revisited I’ve commented on the desirability of separating Internal Releases (or Potentially Shippable Increments) from External or General Availability Releases. Although not directly represented in the Big Picture itself, this is the assumption behind the Agile Release Train graphic in the model. This creates a separation of concerns that allows development to work on the fasted possible pace, producing PSIs at an even and fast cadence, while the market and our marketing teams make the appropriate decisions as to what gets released to customers and when.

In a recent article entitled to To Release No More or to Release Always, posted for free download at the Cutter Consortium, (note you’ll need to enter the promotion code RELEASEMYTH) Israel Gat of BMC comments on this model as follows:

Think of the in-pipe in this example as engineering and the out-pipe as the business. Engineering can post releases at its own pace. The business can selectively choose from the posted releases. In this paradigm, marketing is not obligated to promote a release upon its completion. Marketing might do so in three months; it might choose to promote the current release with another release due at a later time; it might choose to make a release available on a limited basis; or it might choose never to promote a release.

He then goes on to note an even more potentially aggressive release postulate:

An intriguing question poses itself if you accept this premise of asynchronous operation. If the business is free to determine how it will promote a release in the market, why should engineering be bound to producing releases in the traditional manner? Can everyone benefit from relaxing the constraints that usually surround a release and move toward a more flexible, fluid release concept?

Ryan Martens, Rally Software’s CTO, commented on both this article and indirectly on the method behind the madness of the Agile Release Train in his recent post at Agile Commons, Ryan notes:

As a result, I coach most agile teams to start by making sure their “internal release” cadence is twice as fast at marketing, operations and the market is used to.  In this way you get a release where you can gain feedback and steer the “external release” to market better.

Couldn’t have said it better myself.

–Dean

Advertisements

Enterprise Agility – The Big Picture (13 continued): Estimating Epics

Note: In the post Enterprise Agility: The Big Picture, we introduced an overview graphic intended to capture the essence of enterprise agility in a single slide. In a series of continuing post (see the Big Picture Category on this blog ) we have been gradually working our way from the bottom (stories, iterations and the like) towards the top to where the enterprise vision originates. In the last post Portfolio and Vision, we briefly described the Epics that drive so much of the behavior of the agile teams at Level 1 and 2. In this post, we’ll talk about Epic estimation.

big-picture-epic

Big Picture 13 (continued) - Estimating Epics


Everything Starts with the User Story

Before we discuss estimating Epics, however, we must return to Level 1where the teams do their work. In an earlier post, we discussed the User Story.  This is the artifact used by agile teams to communicate the basic intent of the behavior of the system, heavily weighted towards descriptions which clearly deliver value to the user. User stories are captured and maintained in a team’s Backlog, where they are prioritized, estimated and held until they are to be implemented. Estimating user stories is a team skill that all agile teams must master. The aggregate amount of story points that a team can deliver in the course of the iteration is the team’s velocity, and every agile team has one and maintains it routinely. Velocity represents the amount of user value (number of story points) that a team can deliver over any particular time box. Story points can be measured in the abstract (story points) or as Ideal Developer Days (IDDs), with the abstract measure being the most common.

To learn how to estimate points in the abstract, teams are taught relative estimating, often with the simple exercise below:

Exercise: Assign “dog points” to each of the following types of dog to compare their “bigness”: Labrador Retriever, Dachshund, Great Dane, Terrier, German Shepherd, Poodle, St. Bernard, Bulldog.

With this exercise, teams learn how to assign a “relative bigness” to each dog (or story) without debate or concern for the actual units of measure. Then they use that scale to estimate their upcoming stories and after a few iterations, they know their initial velocity (story points per iteration) by counting the points for all completed stories. When teams change size, or vacations or holidays occur, they simple adjust the expected velocity in each iteration and plan for a greater or lesser number of stories as indicated.

Estimating Delivery of Features or Epics

At the Feature or Epic level, our estimating model can be the same and it builds on the basic agile estimating team skill. We simply estimate these bigger items relative to each other and maintain the relative estimates in the Release or Portfolio Backlog. However, while that part is relatively straightforward (but admittedly it is not so straightforward to compare unlike things to each other), even relative sizing gives us no idea when a team can possibly ship what.

For this next step, we are dependent on the Big Picture’s model of expressing system behavior in terms of the parent-child relationship implied by Epics, Features, and Stories:

>> Epics cause Features to exist; (features are “children” of the epics that spawned them)

>> Features cause Stories to exist; (stories are children of the features that spawned them)

>> Stories are the native implementation unit and are also used to measure Velocity

All that is well and good but it still doesn’t tell us anything about when we can deliver what to whom. For this we need some tracking information which allows us to translate Epics into story points. Fortunately, competent agile project management tools (every agile enterprise will likely have one) support this hierarchical model and will have captured historical story point data for earlier Features and Epics. Given an understanding of what percentage of the team’s time we are willing to devote to the new item, we can use historical data  to predict how long it will take to deliver a new Epic. (Example: Epic A was implemented in about 1,000 story points and took X months; Epic B is a little bigger, therefore B will take a little longer).

The Estimated Cost of an Epic can also be Derived

This provides a rough estimate of the time it might take to deliver an Epic based on teams (and teams of teams) actual velocity. It still doesn’t give us any notion of cost. While the teams themselves may not have a one-for-one translation of a cost of a story point, at the portfolio level it is fairly straightforward to calculate one. Simply, look at the burdened cost for any timebox for the set of teams most likely to implement the new Epic and divide that by the number of story points they achieved in the same unit of time. This gives an estimate of the cost per story point for the subject teams in that domain. So if a story point costs, for example, $1,000, then more story points cost more.

A Big Note of Caution

I suspect that you’ve already applied caution enough with this imprecise, yet effective agile estimating model. However, one additional and critical factor is the assumption that all a team’s story points can be dedicated to a new initiative. That is rarely the case as most teams run from 20-50% of their total capacity supporting the existing product with necessary features that are “below the radar” of the portfolio level, as well as resolving defects, performing research spikes, refactoring and other work items that may not contribute so immediately to new user value. So in applying this model, one must be aware of how teams measure their velocity and base the time estimate (but not the cost estimate) on the velocity which is actually available to be used for new Epics.

That’s it for this post. The next post will likely be a miniseries (a post or two or three) on that last big box to the left, the Agile Portfolio.