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:
- Just say no to waterfall thinking
- The seven deadly sins of Feature Preparation
- What does it mean to be Feature ready?
- Some practical tips to avoid waterfalling Features (this article)
abstract
As indicated in the ‘Ready’ checklist presented in the previous article in this series, there are many practical things that can be done to prepare the Features prior to the PI planning event. As previously discussed we do not want to break the Features up into a comprehensive or definitive set of stories prior to the PI planning event. This is demonstrably counterproductive.
Rather than spend time trying to find all of the stories, we have found the following activities to be more useful:
identify some coarse-grained starter stories
Although it is a mistake to try to identify all the stories before the planning event, providing a few ‘illustrative’ stories to help the team get their conversation started and avoid ‘blank page syndrome’ can be very useful.
do an architectural impact analysis
Assessing the architectural impact of the Feature and identifying the components affected, particularly where significant changes or refactors will be required, can be very useful to the team. It also allows the architects to understand which Features they should be actively involved in. Note: here we are treating architecture holistically and including concerns such as security, UX, data etc. all under the heading of Architecture. Many of the teams we work with routinely flag the Features that are architecturally significant and in which specific area of concern.
consider governance and compliance
Does any additional governance, compliance or standards beyond that defined in the definition of done apply to this particular Feature. Some Features have more inherent risk than others and require more detailed scrutiny.
do a test impact analysis
Is there any specific testing required for the Feature – for example does the Feature have a particular affect on any of the systems NFRs or require any additional exploratory or performance testing to help satisfy its acceptance criteria? Many teams need some additional help in designing and implementing less common types of testing so giving them a head’s up in this area can be invaluable. Considering the overall test approach for the Features before the PI planning can also help the program team to ensure that the right test resources are in place for the PI.
do some stakeholder analysis
Where did the Feature come from? Who’s interested in it? What business processes does it support? What personas are involved? All essential information for the team when identifying the Stories and planning their work, particularly the on-going collaboration with their users and stakeholders that will be essential whilst evolving their solution.
socialize the features with the teams
Although the exact priority and the final set of Features for consideration won’t be clear until just before the planning event itself, the themes and expected features for the next PI will emerge during the current one. These can be socialized with the whole of the Product Management / Product Owner group and made visible to the teams themselves. The final list itself can be made available prior to the planning event so that teams can get an idea of the big picture and the relative priorities. Socialization of high priority Features is a good thing to do, but do not allow teams to spend too much time analyzing all of the Features, as some Features may drop out of scope and so this time would be wasted.
Rest assured, you will not need to apply every single one of these activities for every single Feature in your program backlog. For example:
- Many Features will have no significant architectural impact and will only require normal amounts of testing.
- You don’t need to socialize every Feature. You should only socialize the highest priority and most unusual Features with your teams.
- And most new Features will not be impacted by additional governance and compliance issues.
It is however always worth considering the potential wider impact of each Feature as this will impact on the estimate used when prioritizing the backlog and provide useful information to help the team quickly get started on their own story identification and planning.
The key mantras here are always ‘just enough, just in-time’ and ‘defer decisions to the last responsible moment’. Experience tells us that you really should identify the Stories for a Feature and plan the teams’ work at the PI Planning event, or when the PI is in flight - and not during preparation for the Planning event.
conclusion
We hope this series of articles will help you avoid some of the more common pitfalls of using Features to drive your agile development at scale. Remember just say no to waterfall practices in all their many disguises. Just say no to waterfalling your Features and stay agile!
or
More Great Agile Content from Ivar Jacobson International:
- How Many Features do you need for PI Planning
- WSJF & Feature Slicing
- All about the PI Planning Management Review & Problem Solving
- Secrets of Dispersed PI Planning
- Estimating in Story Points