- 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
- Make them more challenging to implement simultaneously and
- 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.