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 (this article)
- What does it mean to be Feature ready?
- Some practical tips to avoid waterfalling Features
abstract
So what are the worst things you can do to compromise the agility of your program when using Features? Here are the seven deadly sins of feature preparation, the most wasteful practices we have seen teams adopt in an attempt to be better prepared for the PI Planning event.
Apologies for the tenuous connection to the original sins, but there were seven sins, honest!
Pride – Pre-Defining all the Stories
The sin of pride, believing you are better than the others.
Now many of the problems related to preparing features could be put down to pride, but ultimately the worst of these is pre-defining all the Stories up front because, of course, the Product Managers and Product Owners know best.
Pre-defining all the stories for a Feature or a Release is the classic hang-over of waterfall requirements management practices and order-taking mentality where we: 1) define all the stories up front, 2) implement all of them without any further discussion or negotiation, and finally 3) accept the Feature as done because all of the Stories have been done.
The goal of the team is not to implement all of the stories but to provide a system that enables the benefits of the Feature to be realized, and to do this with as few stories as possible.
Ah, I hear you say, but what if we involve the whole team in the definition of the Stories? This would help us to reduce the time needed for PI Planning and keep us agile. To which we can only say, it might but generally it will take as long outside the PI Planning meeting than it would in it, saving us nothing. Experience tells that it will actually take longer leading to the gold plating of the stories and less agility once we start the real work. We must hold onto our lean principles and create the Stories at the last responsible moment, which, for the initial set of Stories, is the planning event itself.
Sloth – Freezing the Scope
The sin of sloth, working without care and an absence of interest.
You may think that sloth would lead to the Features being ignored and un-prepared but actually it manifests itself in something far more pervasive than that: Freezing the Scope.
The exact scope of a Feature is something that should emerge from the on-going discussions between the Product Owners / Product Managers and the team, and the fast feedback achieved by quickly building and demonstrating the first Stories.
Any attempt to freeze the scope of a Feature prior to, or even during, the planning event is counter-productive. We would like everyone to continuously focus on innovative ways to reduce the scope and deliver the value as quickly as possible.
Lust - Gold Plating the Feature Description
The sin of lust; the intense, unbridled desire for things you typically haven’t got.
It is easy to see how lust, along with greed, gluttony and the other sins could easily impact the prioritization of the Features but how does it impact on the preparation of the Features?
It is easy to forget that the scope and acceptance criteria for a Feature are all negotiable. If Product Managers invest lots of time and effort polishing their Feature definitions to reflect their every desire then their ability to negotiate on the extent of the Feature is often severely compromised.
Remember the Feature is just a placeholder for an on-going conversation between the Product Owners / Product Managers and the team. It is not a contract or a specification that the team has to adhere to. And there has to be room for negotiation.
Greed - Maximum Possible Features
The sin of greed; the pursuit of more than is needed.
Another hangover from waterfall practices is the ‘greedy Product Manager’ mindset. The “if I don’t get the story as part of this Feature I’ll never get it” mentality that leads to Feature bloat and potentially on-going scope creep. The goal should always be to achieve the ‘Minimum Marketable Feature’ (or for any enabler Features the Minimum Viable Feature) – by this we mean completing the smallest set of stories that will enable the Feature’s benefits to be realized. Additional, nice-to-have stories should be sliced off into their own separate Feature for consideration in a later PI.
Wrath: Disenfranchised Product Owners, Disenfranchised Teams
The sin of wrath; uncontrolled feelings of anger, rage, and even hatred.
Here it is the wrath you will create by mistreating your features, and by implication your teams that you need to watch out for. You’ll never be agile if your behavior demeans and disenfranchises people rather than empowers them.
The Product Owner’s job is to own the team backlog, prioritize the stories, connect the team up to the relevant users and other stakeholders, and find creative solutions to the problems faced by the users. Presenting the Product Owners with a pre-defined set of stories to ‘manage’ the delivery of, often leaves them feeling disenfranchised, de-motivated and trapped. This is not good for them or their teams.
If you let the Product Owners pre-define the stories for a Feature then you don’t solve the problem as their teams will now become disenfranchised and de-motivated leading to an unhealthy ‘hand-over relationship between the development teams and the Product Owners and Product Managers.
Gluttony - Believing the initial estimate
The sin of gluttony; the over consumption of anything to the point of waste.
By initially under-estimating the Features prior to PI planning and then forcing, directly or indirectly, teams to conform to these estimates we turn the teams into gluttons. Continuously taking on more Features than they have the capacity for.
With the investment in preparing the stories for the Feature comes the illusion of better, more predictive estimating. This often leads to the Features having estimates that the leadership team believe to be accurate and precise, and, most dangerously, correct. The teams then feel duty bound to conform to these estimates and use them for planning purposes rather than producing their own estimates reflecting what they’ve learnt during the planning session itself.
Envy: My Feature, My Team
The sin of Envy; sad or resentful covetousness towards the traits or possessions of someone else.
Six down, one to go and we hit the most dubious of the sin relationships.
In many traditional planning processes the management compete to get the best people for their teams, or in a more agile world the best teams to work on their Features. This mindset leads to people coveting particular teams and once they get hold of them behaving selfishly about the contributions that the teams will make to the greater team-of-teams. To the extent that it can de-rail the train.
For example: Rather than allowing the teams to select the Features dynamically from a prioritized backlog the ‘leaders’ want to allocate them to teams, and once the teams have been identified control them, feeding them more and more of their own Features. Not anyone else just their own. Even if their Features are not as beneficial to the business as other people’s.
This behavior can also manifest itself through-out the team-of-teams as velocity envy – a sin that can lead to story point inflation, selfish behavior between the teams, and a focus on velocity to the detriment of value.
And now a special bonus sin. The waterfall mindset can be so pervasive and hard to shift that we need an extra sin.
The Original Sin: The Pre-Allocation of Features
Originally the seventh sin was going to be “Pre-Allocating Features to Teams” but on reflection it became clear that 1) this wasn’t really a sin related to Feature preparation and 2) it was just the ultimate manifestation of the other seven sins. It is, to say the least, a product of pride, greed, gluttony, lust and sloth if not envy and wrath (fear the wrath of the disenfranchised project manager for they will allocate you Features with fixed scope and fixed estimates preventing you from being a true agile team).
This recidivist behavior has many roots including:
- Trying to reduce the length of time spent planning – it doesn’t unless you don’t involve the teams in the pre-planning work and then not really agile any more
- Trying to reduce the risk that the teams will do the wrong things – it doesn’t it just concentrates the decision making leading to greater risk of producing a plan no-one believes in or is prepared to commit to.
It can also result in teams being overloaded and the team-of-teams not getting to deliver the most important Features as they were allocated to the wrong teams.
- Trying to define all the Stories up front (see Pride above) and wanting to get the team involved in the discovery of the Stories.
- Trying to cover for skills and knowledge gaps (ah the sin of pride that gets us to think that we know best) in the Product Owner community or the teams themselves.
Ultimately it involves falling prey to the other seven deadly sins. This is what makes them so deadly, their inherent selfishness and implied superiority ultimately leads teams back into waterfall behavior.
Taken together these sins can derail the whole PI planning process, demoralize the teams, and compromise the whole move to agility. They are all symptoms of hanging onto a waterfall mindset – teams will never realize the full benefits of adopting a lean and agile approach, or even become lean and agile, if they waterfall their features.
But it’s not all doom and gloom. In the final two blogs in this short series we will look at some practical things that can be done to prepare the Features prior to the PI planning event. In the mean time just say no to waterfalling your Features and stay agile!
What does it mean to be Feature ready is next in the series
or
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