Preparing Features for PI Planning - Part Three

What Does it Mean for a Feature to be Ready?

A lot of work goes into the continuous refinement of a product’s backlog. This is true as much for Feature Backlogs as it is for Story backlogs. When using SAFe® if it often seems that too much work goes into preparing the Features and getting them ready for PI Planning. This series of blogs focusses on various topics concerned with preparing Features for PI Planning:

Download the Feature State Cards that go with this article below

So what does it mean for a Feature to be “Ready”? And just as importantly when do they need to be “Ready”?

As many people have observed (Read Mike Cohn’s article) Definition of Ready can be a dangerous thing leading to waterfall behavior and strict hand-overs between Product Owners and their teams. In many cases teams would be better off not having one as it often stops them from working on the most important Feature because they believe it’s someone else’s job to get it ready. But keeping this in mind, what would make a suitable definition of ready for a Feature?

As we’ve seen in the previous blogs in this series; it definitely doesn’t mean that all of the Stories have been identified. In fact, a Feature can be ready even if there are no Stories identified.

Personally, we’ve always been fond of Roman Pichler’s simple definition that to be ready a backlog item should be clear, feasible and testable. This applies as well to Features as it does to Stories, and provides the first ready test for any Product Manager to apply to their Features. If they don’t feel it is clear, feasible or testable they shouldn’t be letting it anywhere near the top of their backlog and into their next PI.

For Features it is worthwhile taking a look at what each of these means.

  • Clear – It is clear what the feature means and how it will benefit the customers, users and other stakeholders. Basically, the Product Management / Ownership community can readily explain what the Feature means and explain its intricacies to the development team. If they don’t have the knowledge to explain the Feature and answer the development team’s questions then they are not ready, and by implication neither is the Feature.
  • Feasible – it is technically feasible to implement the Feature. This implies that the estimate is accurate enough for prioritization purposes (so the Feature doesn’t have a false position in the backlog), and is small enough to be completed within a Program Increment (PI). If there is too much uncertainty or technical risk related to the Feature then an enabler Feature should be broken out to directly address the issues. If the it is not easily understood how the Feature will implemented then the Feature is not ready.
  • Testable – it is understood how the Feature will be tested. Not just how its Storied will be tested but also how the Feature as a whole will be tested. In particular it is useful to know whether or not any new or unique types of testing are required. If the Feature is not testable then it is not doable, and therefore not ready.

It is also critically important that any Features selected conform to Bill Wake’s incredibly popular INVEST acronym, which describes the properties of a well-formed backlog items. An acronym that applies as much, if not more, to Features as it does to Stories.

Again, it is worth taking a look at how thinking INVEST can help us to prepare our Features properly.

  • Independent – all Features should be thought of as independent from all other Features, particularly when prioritizing and preparing them prior to a PI planning meeting (i.e. getting them Ready). There may be a natural order to the Features in that Feature 2 doesn’t make a lot of sense if Feature 1 isn’t in place. This doesn’t imply dependency as we could implement Feature 2 before Feature 1 if we wanted to, but that doing them in this order wouldn’t make any business sense.

Sometimes Features will require the same changes to be made to the codebase or even contain the same Stories. This doesn’t make the Features dependent on each other but can 1) make them more challenging to implement simultaneously and 2) lead to changes to their estimates as the overlapping Features are implemented. This potential overlap is one of the reasons we like to do collaborative PI planning with the whole team. By simultaneously planning the work on a set of Features the teams can discover and collaborate to exploit any overlaps helping the team-of-teams to deliver even more Features.

  • Negotiable– This one is the big one as not only is the priority of the Feature negotiable so are its extent (the number of stories it involves) and its acceptance criteria. PI planning is not just about planning but also negotiating the scope and extent of the Features being planned.
  • Valuable – it should go without saying that all Features should have clear value to the business and benefit for the users and other stakeholders.
  • Estimable – If the Feature can’t be estimated then it can’t be prioritized. You cannot prioritize a backlog on value alone. Note: the estimates will change over time as Features can overlap (see Independent above) and need to be estimated against the current state and capabilities of the system – an estimate which may well change every PI.
  • Sized Appropriately / Small – All Features should be sized appropriately for their position in the Backlog. If the Feature is under consideration for implementation in the next PI then it needs to be small enough to readily fit in the PI. If it isn’t it will need to be sliced. If the Feature is not going to be implemented until a subsequent time-box then it can be any size it likes. If you’re never going to do it then who cares how big it is
  • Testable– see the discussion above.

Taking all of this into account, and focusing on what it means for a Feature to be ready to be used as input into PI planning we have put together this simple checklist.

Feature Ready: The Feature is clear, well understood and small enough for a team to be able to plan its completion.

The Feature can be clearly described. The feature is well enough understood that its extent and purpose can be clearly explained by the Product Management / Product Ownership Team

Small enough to fit within a PI The estimates for the Feature indicate that it is small enough to be easily completed within a standard Program Increment (PI).

The Feature is testable The need for any unusual or novel testing is clear and factored into the estimates

The Feature is feasible For Business Features the architectural and technical risks are under control and it is expected that the Feature can be implemented without any significant technical issues. For experimental enablers and spikes the constraints are understood and the financial exposure is in-line with the probability of success..

The potential benefits are understood The Feature has a well understood, measurable benefits hypothesis.

The Feature has a clear owner It is clear who the team pulling the Feature should converse, and negotiate with, over the scope and extent of the Feature, and who will accept the Feature as done.

The level of key stakeholder involvement is understood. The details of any important external Stakeholders are known and the mechanisms to involve them in a timely way have been put in place.

The cost of delay is clear The relative business / user value, time criticality, risk reduction and opportunity enablement are well enough understood that the Features cost of delay is clear. See the SAFe approach to Weighted Shortest Job First for more details.

Any ‘fixed’ requirements are known Any specific, fixed, non-negotiable aspects of the Feature are known and their details are available. For example the specific actuarial calculations to be used in an insurance system.

This checklist, as shown in Figure 1, is also available as one of a set of 6 mini-checklist cards that together define the lifecycle of a Feature.

Figure 1: Checklist cards for Feature Evolution

If things go to plan future blogs will further explore the lifecycle of a Feature and the other checklists, but the full set of cards are available for download now below, along with an editable copy of the Ready checklist. Complete the form below to receive the one page PDF of the Feature cards.

In the final blog in this series we will provide some practical advice on activities you can do to get your Features ready for PI planning without falling prey to the seven sins of feature preparation and back into waterfall behavior. Find it here: Some practical tips to avoid waterfalling Features


More Great Agile Content from Ivar Jacobson International:

Contact Us