Part 3: What Does it Mean for a Feature to be Ready?
Read Part Two here Read Part Onehere
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.
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.
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.
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 TeamSmall 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
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.
Scaled Agile Framework, Agile Transformation
View the discussion thread.