What does “negotiate” from the invest framework mean during sprint planning?

Author(s)
Ian Spence

Part 3: What Does it Mean for a Feature to be Ready?

Read Part Two here Read Part Onehere

Download cardsbelow

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

As many people have observed (Read Mike Cohns 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 its someone elses job to get it ready. But keeping this in mind, what would make a suitable definition of ready for aFeature?


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

Personally, weve always been fond of Roman Pichlers simple definition that to be ready a backlog item should be clear, feasible and testable (see http://www.romanpichler.com/blog/tag/definition-of-ready/ for this and more great advice). 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 dont feel it is clear, feasible or testable they shouldnt be letting it anywhere near the top of their backlog and into their nextPI.

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

  • 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 dont have the knowledge to explain the Feature and answer the development teams questions then they are not ready, and by implication neither is theFeature.
  • Feasible it is technically feasible to implement the Feature. This implies that the estimate is accurate enough for prioritization purposes (so the Feature doesnt 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 (see Feature Slicing article published at the scaledagiledframework website). If it is not easily understood how the Feature will be implemented, then the Feature is notready.
  • 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 notready.

It is also critically important that any Features selected conform to Bill Wakes 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 toStories.

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

  • 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 doesnt make a lot of sense if Feature 1 isnt in place. This doesnt imply dependency as we could implement Feature 2 before Feature 1 if we wanted to, but that doing them in this order wouldnt make any businesssense.

Sometimes Features will require the same changes to be made to the codebase or even contain the same Stories. This doesnt 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 moreFeatures.

  • 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 beingplanned.
  • Valuable it should go without saying that all Features should have clear value to the business and benefit for the users and otherstakeholders.
  • Estimable If the Feature cant be estimated then it cant 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 everyPI.
  • 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 isnt 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 youre never going to do it then who cares how big itis
  • Testable see the discussionabove.

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 simplechecklist.

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 PIThe estimates for the Feature indicate that it is small enough to be easily completed within a standard Program Increment (PI).

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

The Feature is feasibleFor 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 understoodThe Feature has a well understood, measurable benefits hypothesis.

The Feature has a clear ownerIt 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 clearThe 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 knownAny 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 aFeature.

Figure 1: Checklist cards for FeatureEvolution

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, along with an editable copy of the Ready checklist. Complete the form below to receive the one page PDF of the Featurecards.

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 waterfallbehavior.

Read Part4.

Subject
Scaled Agile Framework, Agile Transformation
Tweet

View the discussion thread.