Continuing on with end-to-end planning techniques within agile contexts –

Crystal Blitz Planning

Alistair Cockburn’s gets very little attention in the agile community. In many ways it’s one of the forgotten agile methodologies. So it hasn’t been well received as a method, but I like to “mine” Crystal for techniques and ideas to supplement my agile methods coaching. The notion of a “Walking Skeleton” from Crystal is useful in speaking about emergent software architecture. And in the release planning area, Crystal’s notion of Blitz Planning is useful as well.

The best description is in the . Blitz Planning is a multi-part, team-based approach to pull together a high-level view to all of the work (and supporting work) to deliver on a projects goals. It doesn’t prescribe a specific release interval (period, or set # of sprints). Instead it lets the scope of work drive the # of iterations in the Blitz Plan. That and the scope of work related to creating production-ready product.

References

• Crystal Clear book –

User Story Mapping

is the creator of this practice. and he have collaborated on a refined the practice. It’s an exception to this list in that it’s not entirely a planning approach. It sort of is and it isn’t. The primary focus is on User Stories graphically not as a functional or requirement perspective, but as how the User will see, feel and use the system as it develops. I would consider it a UX technique.

It lays out your stories in 4 levels:

1. Backbone – stories focused on major functional areas of customer usage
2. Walking Skeleton Tasks – smaller stories that support the Backbone; a minimalist view to functional requirements
3. Sub Tasks & Task Details – smaller stories that support the Walking Skeleton or finer grained understand (for example, acceptance criteria).
4. Infrastructure – what I might call “glue stories” that provide infrastructure and support for the Walking Skeleton. Typically dependencies.

I actually recommend doing User Story Mapping as an adjunct to Release Planning; usually before the planning. So the sequence becomes: Backlog creation & Grooming -> Story Mapping -> Release Planning. This way you’re putting customer problem solving and functional usage before actually planning iterative and release deliverables.

References

SAFe – Release Train Planning

A relatively recent development in the agile community is a strong focus on Enterprise-level, scalability models. has introduced the or SAFe. has introduced or DAD. and Bas Vodde have co-authored two books and are working on a third that is focused on “agile at scale” techniques and practices. is starting to talk about Agility Path and on the Scrum.org site. And there are still others that are getting into this space.

There has always been the venerable Scrum of Scrums model. It often gets overlooked because there is so little tactical guidance on how to effectively implement it. One reference for it is in my book.

Dean has long described a release model called the Release Train. It predates all of this enterprise-level hoopla and was simply an iterative view towards how to build and guide a series of iterations or sprints into a “shippable product increment” instead of a “potentially shippable product increment”. It turns out that there is usually quite a lot of preparation and work to release something that isn’t all about deliver user stories or features.

SAFe describes a 2-day Release Planning meeting that aligns with the Release Train and a Potentially Shippable Increment (PSI)

References

Agile Project Chartering

If you were to ask me – where do these sorts of techniques fit within agile project management, I would probably say this:

First, for straightforward or single team agile projects, many of these longer term planning activities are unnecessary. The regular planning activities associated with your agile methodology will take care of things. But, and I mean but, if you’re working on

• A distributed project or a partially or full outsourced project
• A complex project
• A multi-team project
• A project with many dependencies
• A project with Waterfall dependencies
• A software plus hardware project
• A project within a regulated industry
• A project with large scale testing requirements
• A risky project
• A project that required some upfront design decisions

Then you might want to strongly consider these techniques. And not simply as part of some standalone effort, please no, but instead as part of CHARTERING your project. Much of this early, release level planning occurs during traditional project chartering phases of projects.

The book by Larson & Nies covers quite a few approaches to agile chartering.

References

And you might want to read a more “traditional” book on software project management and chartering to gain a feel for the depth and breadth of solid chartering, for example, . Starting agile projects off is something that many agile teams skip—preferring to simply “dive in” and start sprinting. It’s often a huge mistake.

Wrapping Up

I hope that this “walk” through a bunch or practices has helped you to understand that there is available wisdom, in some depth and breadth, surrounding agile planning. Sometimes I think we get to be so “agile” in our thinking that we forget some of the practices we’ve learned over the years and how useful they are in specific contexts. So I hope I’ve inspired you to do some research and study and to consider agile project chartering and release planning as one of the tools that should be in your agile toolbox.

Between us, I rarely find a company or project context nowadays that doesn’t support doing a little chartering and release planning. While I might scale it down, not doing it is normally not an option to me.

Finally, I just noticed the other day that David Hussman’s videos are no longer being sold on the Pragmatic Bookshelf. These were professionally recorded sessions that at one point he was selling. Not sure what happened, but now they’re available for free on his website.  What a remarkable gift for the agile community.

David Hussman’s video’s cover quite a few of these areas:   Highly Recommended!

Finally, I wrap up this 3-part series on Agile Release Planning with a final, more normal format , post. You can read it here.

Stay agile my friends,

Bob,

* – the photo is licensed under Creative Commons Attribution – Share Alike 3.0 license by Luna04 via the French Wikipedia.