SAFe Value Delivery & Capability Runways

October 26th, 2014 No comments

Some people are adamant that every Program & Team backlog item must deliver tangible user/customer value (INVEST). There is no room in the Program or Team backlogs for extraneous items that need to be performed as part of the supporting work. Training? Either reduce your velocity or add it as tasks to ‘Value’ stories.

The argument might go something like, “You can’t have ‘As a developer I need training in XYZ so I can deliver the ABC Feature.’” and “’As a Program we need a System Test Environment for the Release so we can perform System tests’ is not a story.”

“These are all tasks, so add a task to each story or just do them in your ‘buffer time’”, or “Everyone has to attend that training, so just reduce the Planned Velocity for the sprint by 8 points.”

While there are cases where these should be tasks, there is no prescribed approach other than “don’t add a story, don’t size it, it is not adding Value.”

In SAFe, we read that the Sprint Backlog contains ALL the things that need to be done, whether it be User Stories, Refactors, Defects, Research Spikes or other Technical Debt. Although it doesn’t specifically state anything about ‘foundational’ items such as building the test environment or generic training, should these be treated differently?

Clearly these Backlog Items do not directly produce user-centered functionality, yet they are there and do offer value (if not, then why do them?). Further, I think you can appreciate that these Items should have their own Conditions of Satisfaction and are not simply Tasks.

While this might seem like a style choice that, as long as it is consistently applied across all teams in the Release Train, isn’t a big deal, I think that it raises a broader question and exposes an opportunity regarding how we determine what we work on and how we define and measure Value.

So what do we mean by ‘Value’?

In a Value Stream, we are typically interested in all the activities related to understanding needs, building and deploying solutions that provide value to End Users, Customers or even Internal Business Processes. To this end, in SAFe, we discover Value Streams and manage backlogs of Features at the Program level, derived from Epics, that we believe will deliver value, and we manage Team Backlogs at the Team level that contain the Items that need to be done in order to deliver those Features.

The really nice thing about this is that the Program Backlog unambiguously carries the Value Items. The Features. As such, we can compare the values of Features, we can be clear as to which Epics they contribute and we can do fancy prioritization using WSJF. We can spend our money wisely. The Conditions of Satisfaction for a Feature drive the Teams’ Backlog Items. We can measure and discuss the done-ness of Features with the business. We can establish a Program Velocity based on Feature delivery. Effectively this is a measure of Value Velocity. Great!

What about a Team’s Velocity then? What good is that for?

Do I measure a team’s value contribution by only counting stories that delivered end user functionality? The Team’s Velocity is all about predictability. The team wants to know how much ‘effort budget’ it can spend in the sprint. The Team’s responsibility (includes the PO) is to establish the optimal set of Items that will deliver the highest Value for the Program. Remember, the whole Program is sprinting together.

By the way… if we disassociate Feature Points from Story Points, we overcome the need to normalize Story Points; each team can do whatever they want to establish their unique velocity; we just need predictability at the team level. The Program’s Capacity and Velocity can be expressed in Feature points. With Feature Points, we can avoid Features being sized using a 10x factor, and Epics equal to 4000 story points. (my work colleague Jim Schaeffler, SPC, has some interesting ideas on how to measure Feature Points)

Value & Runways:

When we look at SAFe, we notice that there are some special Features denoted in red; Architectural Features. These have been derived from a variety of sources: Architectural Epics that define Enterprise-Level Intentional Architecture, Program Vision and Roadmap intent that expose the need for Architectural Features, and specific emergent design challenges.

In SAFe we want our architectural implementation to be just enough and just in time. We want to avoid Big Up Front Design (BUFD). SAFe uses the term ‘Runway’ to connote the laying down of ‘consumable architecture’ just far enough ahead of the development of the Features that require it. I would rather it be a ‘Railway Track’, given that we have a Release Train… but no matter. The point is that while some of these ‘special features’ do provide direct end-user Value in terms of commercially-important capabilities such as Performance and Security, many provide a supporting or enabling role related to quality and integrity of the system, which are deemed to be of Value and worth spending team effort on.

You knew that already. So why bring it up?

When we need to improve our Architectural Capability, we lay down our Runway. I think SAFe might benefit from recognizing that there are other ‘Capability Runways’ that need to be in place before a Feature can be delivered: ‘Knowledge (know how) Runway’, ‘Technical Infrastructure Runway’, ‘Physical Environment Runway’, ‘Organizational Runway’.

The company could express Strategic Intent by inserting ‘Capability Epics’ into the portfolio. These can be budgeted (because they don’t come for free) and aligned and prioritized against the classical ‘Business Value’ Epics so that the company has the resources and necessary environments in place to support its goals. The Features would be prioritized into the Program Backlogs just like Architectural Features are.

So… when a team asks what to do about training that they have to take in order to understand a new aspect of their work, you can tell them to add a sized Backlog Item that is tied to a Feature for this PI, such as F5005-Automated Test Training. Such a Feature would have a clear value proposition and Conditions of Satisfaction; after all, we are spending precious team time on achieving the capability.

Perhaps, when they ask about setting up an Environment Story, you can point them to a Feature for the Infrastructure Capability Runway that they can link to.

I can imagine that Capability Runways would be very active in the early days of SAFe adoption, for example, eventually settling down to contain Capabilities that are required to deliver classical Value for a Value Stream or to accommodate a Corporate Initiative as part of continuous improvement.

What do you think about the concept of Capability Runways? Do you think it would be useful to be able to explicitly plan and understand the impact of building a capable workforce with suitable environments?

Agile Sprint Planning: A Well-Groomed Product Backlog

September 12th, 2012 2 comments

For me, one of the toughest challenges I face with a ‘young’ Agile team, is Sprint Planning.

Agile Planning, to some, seems like a contradiction in terms (like the old “Military Intelligence” joke). Yet planning is the essence of Agile, be it at the Portfolio, Release, Sprint or Daily level. Planning is the mechanism that allows a team to put a stake in the ground and say, “Let’s commit to trying to get to THAT place over there.” Planning provides a degree of predictability, or expectation, for a Product Owner. It allows a Marketing team to have some idea of when to ramp up the advertising campaign.  Planning is all about working out ‘the right amount of the right stuff at the right time.’

Today, I’ll share my thoughts about a Well-Groomed Backlog.

The Product Backlog is the list of stuff that the team will potentially work on. It contains feature requests, bug-fix requests, technical requirements (infrastructure, upgrades etc) and other team-related activities required in order to enhance or support the Product. I recommend you check out Mountain Goat’s definition .

Even though Product Backlog Grooming is ultimately a team endeavor, the Product Owner owns the Product Backlog. So there’s the first hurdle: do you have a ‘proper’ Product Owner, and do they know what their responsibilities are? Their primary responsibility is prioritization. Anyone can add items to the Product Backlog, but the Product Owner is the gate keeper of the ‘right stuff at the right time’. On several occasions I have been faced with a team where the Product Owner is actually a team director, tech lead or architect. They don’t own the Product, as such; they own the technical design, delivery and support of the application(s). What’s the problem? Well, in such a case, the Product Backlog tends to become heavily weighted toward product infrastructure and development environment tweaks. Business requirements can get pushed down the stack in favor of ‘improving the build process’ or ‘improving the architecture’. Given that we are trying to deliver Business Value, then having a Product Owner who is responsible for the usefulness/value of the Product is imperative. It may well be that improving the build process or architecture is a valuable investment, but this is a business decision that needs to be made within the context of all other backlog items. So, bottom line, make sure you’re following the Agile guidelines when it comes to appointing a Product Owner.

Now that you have an appropriate Product Owner, you (as a coach and/or scrum master), have to help them, and the team, understand what it means to keep the Product Backlog well-groomed. A well-groomed Product Backlog facilitates Release and Sprint Planning. The stories in the Backlog need to be prioritized in Business Value order, top to bottom (or at least as far down as your release horizon dictates). In addition, at least the next ‘Sprint’s worth’ of stories (the ‘right amount’) need to be appropriately sized, using relative sizing techniques such as point-sizing or ideal-day sizing. ‘Appropriately sized’ means that any story should be completable within one Sprint. ‘Completable’ means that it can be analyzed, coded, tested and accepted as DONE (per the Acceptance Criteria); that it could be deployed if necessary. I’ll talk about sizing in the next post. So now we know what a well-groomed Product Backlog should look like, how do we go about achieving that? Who needs to do what and when?

In an ideal world, the Product Owner has their hands on the Product Backlog helm. During the course of any given Sprint they should be taking a first-cut at the grooming for the next Sprint by reviewing and prioritizing the items in the Product Backlog. This can be achieved by allocating a few minutes a day, or it might be done in a concentrated effort prior to the next Sprint Planning Meeting. It is during that meeting that the team will look to the Product Owner to give enough information about each story such that the team has a clear understanding if the story is feasible for the next Sprint. If the Product Owner did not write the story, then they will have had to have talked with the author in order to understand enough to prioritize it. The team will need to understand what ‘done’ looks like; what are the Acceptance Criteria? They will need enough information to be able to ratify the existing relative sizing or to actually estimate a relative size on the fly.

In summary, a well-groomed Product Backlog allows a team to plan ‘the right amount of the right stuff at the right time’.

Thanks for reading.
Please share your thoughts (with a constructive, kind and gracious sense of purpose, please)


Categories: Fundamentals Tags: