Agile Portfolio Planning and Business Epic Kanban System Overview

My colleague and “agile ninja”, Chad Holdorf, has been working with agile at enterprise scale for some time now. He has adopted the Big Picture from my Agile Software Requirements book, which he describes as a “Scaled Agile Delivery Model” (I like that name a lot; I might even adopt it). Recently, he has been working at the portfolio levels of the enterprise to effect lean and agile thinking there too, and to provide a systematic way of moving projects from the portfolio (enterprise backlog) into development via a set of Agile Release Trains. He’s using the enterprise backlog model I described on my blog and the paradigm of the business epic kanban system , which I describe in Chapter 23 – Investment Themes, Epics and Portfolio Planning, of ASR. He has just published a short video/blog post that summarizes this system brilliantly. Check it out at: http://www.scaledagiledelivery.com/2011/04/22/agile-portfolio-planning/.

In addition, as agile tooling is a necessary condition for success at enterprise scale, he’s been collaborating with Catherine Connor at Rally (as have I) on the development of their new portfolio planning tool called “Stratus”. Here’s what Rally says about Stratus:

“Rally is previewing Project Stratus, a new application that elevates Agile planning and tracking to roadmap and portfolio levels. Based on collaboration with Rally customers, Project Stratus focuses at the PMO level on:

• Keeping development aligned with strategic business priorities
• Visualizing and managing projects and large features across the entire value stream
• Analyzing the roadmap to optimize delivery of value while minimizing risk
• Strengthening feedback loops between the PMO and development teams”

Now ideally, any method (with tooling) that really supported enterprise-level, agile portfolio planning would accomplish a number of objectives:

1. make the backlog of potential and current portfolio projects visible
2. provide wip limits so as to keep the full system in maximum productive flow
3. provide a persistent, single version of the truth in the enterprise (avoid dueling spreadsheets/tools)
4. provide visibility for how current development activities correlate to the enterprises current investment themes
5. provide a capacity-based, systematic way of driving new epics into development

I think you’ll see from Chad’s video, that this system has the potential to accomplish all these objectives.

One last comment: Great job Chad and Catherine! This is clearly “new knowledge” that can help most every agile enterprise.

Amazon Kindle Version of Agile Software Requirements Should be Available Again Soon

To those readers wondering what happened to the Kindle version of Agile Software Requirements, I’ve just been advised by the publisher that there were some technical issues with the files which have now been fixed. The book should reappear in Kindle form by about April 27, but that date is just an estimate.

Sorry for the confusion. It was all news to me, too!

Tooling to Automate User Story Verification

In a recent post, I noted that Craig Langenfeld, my co-contributor on the Agile in High-Assurance and Regulated Environments series, was beginning to describe how tooling can be used to automate (or semi-automate) much of the formal verification activities we’ll need to assure that a) our software works exactly as intended, and b) leaving a traceability-audit trail for the device history records as called out by the company’s quality management system (QMS).

In earlier posts in this series, I described an important sub-thread, which is the verification of user stories in the course of each iteration. I pointed that in order to assure that each new user story works as intended, we’ll want to verify it via three traceability paths:

• User story to code – path to the SCM record that illustrates when and where the code was changed to implement the story
• User story to code-level unit test (the “white box” test which helps assure the new code works to its internal (code level) specifications
• User Story to Story acceptance tests (black box testing of the user story to make sure the system functions as intended)

Craig has recently published his first two posts on this important sub-thread in our larger verification and validation picture. In his first post he describes two things:

1)   How built in story to task relationships increase the rigor and traceability of the TASKS we’ll use to define|build|verify each user story, and

2)   How you can use Rally to persist the story, the story acceptance tests and the story to acceptance test verification paths. (Bullet #3 above).

However, for many practitioners Rally is not the only tool in the project environment, so in a second post he describes how HP Quality Center can be used to perform Verification Testing on User Stories that are planned, tracked, and managed within Rally.

As I mentioned in a prior post in this series, effective, scalable agile project management tooling is a critical component to developing and documenting high-assurance software, so I am happy so see these tooling examples and look forward to the next few posts in Craig’s series. As usual, I’ll keep you “post”ed.

Splitting Epics, Features and User Stories

It will come as no surprise to any agilist that one of the hardest parts of agile development is the ability to split valued, useful work into stories small enough to fit in a sprint. Indeed, team after team has commented on this challenge and they are constantly looking for ways to make this easier, or at least have a variety of techniques to draw on. When you back off a bit for perspective, you also immediately recognize that splitting all user value work, whether it be business or architecture epics, user features, or user stories is actually the primary working metaphor for agile development in general, as building valuable, working, tested increments of code in a short time box, whether sprint or release timebox, requires it. If you can’t do that, then you can’t leave a timebox with potentially shippable code, else you have “hanging chads” littering the development or master code line and you can’t make a sharp turn (be agile) without having to first finish what you should have finished in the last sprint.

So we split and split and split again. The better we are at splitting, the more agile we become.

It’s an important topic, and I’ve provided hints and techniques for splitting user stores and architectural epics in Agile Software Requirements. That’s the best I could do given my experience and what I’ve gleaned from others.

However there is more to be written on this topic, and my colleague, Alex Yakyma from Kyiv, Ukraine has been elaborating on ways to split stories on his website at www.yakyma.com. Alex is an experienced agilist, mathematician and coder, (the parts of my brain I used to use for coding have apparently atrophied over time, oh well….) so he has much in-depth perspective to share through categorizing and examples. He has divided the problem into five categories (types of things to be split). The first post, describing incremental implementation of complex algorithms can be found here: Splitting User Stories. Part 1: Incremental Development of Complex Algorithms.

Today he posted the second post, Evolving Rich UI.

Future posts are intended to cover:

Splitting User Stories. Part 3: Incremental Architecture.

Splitting User Stories. Part 4: Simple Steps in Implementing Complex Scenarios.

Splitting User Stories. Part 5: Evolving APIs, Protocols, Interfaces.

If you are an agile developer or architect in the trenches, you might want to keep your eye on this series.