Product Backlog Gardening, with love!

Wikipedia (btw, the most successful example of an emergent product from a self-organizing team) provides the following definition:

Gardening is the practice of growing and cultivating plants. It involves an active participation and tends to be labor intensive, which differentiates it from farming or forestry.

I cannot find a better metaphor to describe the continuous work that a proficient Product Owner needs to do with the Product backlog.

1. First step is actually to plant a seed. That’s the purpose of defining the Product Vision together with the customer, answering the questions: What do we want to accomplish? And why? All gardeners know that quality of the seed is essential and of course you need to plant cherries if you want to get cherries and you cannot get roses if you plant onions.
2. After you plant the seed, you need to water and fertilize it. Then the first small sprout will come out of eliciting a set of SMART (Simple, Measurable, Achievable, Relevant, Traceable) requirements, focusing on customer needs, on the problems to solve or better on the problems worth solving.
3. The tender small plant now needs a good environment to strengthen and grow. Gather all needed people in a User Story workshop and collaboratively write down as much as stories as possible. You as a Product Owner, exactly like a good gardener, do not have to do all the work yourself: you need proper tools and a fertile land. So use the best land, i.e. the power of the diverse brains around you. Present your Goal for the next Release Cycle and the related Requirements. Make use of creativity techniques to elicit as many User Stories from the Team as possible. Try to identify top MMFs and break them down into User Stories, or cluster User Stories into MMFs.
4. Good User Stories should be INVEST
• Independent: Stories are easiest to work with if they are independent.
• Negotiable... and Negotiated: A good story is negotiable. It is not an explicit contract for features; rather, details will be co-created by Product Owner, programmers and testers during development.
• Valuable: A story needs to be valuable to the customer. Think of your Product as a multi-layer cake: a story is supposed to give the customer the essence of the whole cake, and the best way is to slice vertically through the layers. Developers often have an inclination to work on only one layer at a time (and get it "right"); but a full database layer (for example) has little value to the customer if there's no User Interface.
• Estimable: A good story can be estimated. We don't need an exact estimate, but just enough to help the customer rank and schedule the story's implementation. Being estimable is partly a function of being negotiated, as it's hard to estimate a story we don't understand. It is also a function of size: bigger stories are harder to estimate. Finally, it's a function of the team: what's easy to estimate will vary depending on the team's experience.
• Small: Good stories tend to be small, such that the team can do 6-10 stories in a Sprint as thumb rule. Above this size, it will be too hard to know what's in the story's scope, it will delay the feedback loop and increase the project risk.
• Testable: A good story is testable. Writing a story carries an implicit promise: "I understand what I want well enough that I could write a test for it." Teams are made more productive, by writing customer tests, in terms of Acceptance Criteria, before implementing a story.

INVEST is not only an acronym, but means the Product Owner needs to invest time, energy, skills and, why not , love, to make the plant flourish like all passionate gardeners do. And you cannot achieve it on your own: you can have a say on the "INV" part, but you will never get the "EST" without your team. Remember: Gardening involves an active participation and tends to be labor intensive, which differentiates it from farming or forestry.

5. A good Product Backlog is of manageable size, more granular on the top and more general towards the bottom, so that you do just enough, just in time work. Continuously trim useless leaves to give more space and lymph to the buds going to bear fruit soon: the User Stories being developed in the coming iteration and transformed in a potentially shippable product increment. Nevertheless continue watering and fertilizing the plant, looking a bit ahead to set the stage for later buds and fruits.
6. If you want to collect many fruits after each Sprint and thus maximize the Return on Investment, you might need to split User Stories in smaller chunks. But beware: splitting by architecture or by implementation details is a common mistake. It creates smaller stories, but fails several of the other INVEST criteria and then does not bear fruit. There is no too small story, unless it fails delivering value to customer. You can find a suggestion of possible good patterns to follow when splitting stories and still keep them INVEST here. An awesome and useful mindmap guiding you through the different patterns can be found here.

GIGO theory

One of the biggest causes of poor Product quality is a poor Product backlog, exactly like a sick plant cannot bear juicy fruits: GIGO theory applies J

So are you constantly gardening your Product Backlog with love?

Or are you expecting to harvest without hard work and passion?

I’m sorry to say that you will only collect invaluable fruits, my friend!