For over a year, I am now proud Product Owner of CenterDevice . And all this time I felt bad about myself, how I managed to keep my product backlog in shape. Or rather, how I failed in doing so. Three weeks ago I decided, that it’s not me to blame, but the approach I took. So this is what I changed.
What was the difficulty, I hear you ask? The challenges? CenterDevice is currently a StartUp on the breach of becoming successful. It’s not that we don’t have any customers, quite the opposite. We have so many customers, that all the little things that sales, account managers, support, and management ask for can easily keep you 100% busy. On the other hand, how could it be different, I wouldn’t really mind more customers 🙂
To enlarge the user base, and increase the growth rate, I would like to churn out new features more quickly, try things out, measure if they work, etc.; you know, the usual Lean StartUp approach.
But this was a major challenge for me to organize in the “classic” Product Backlog: A long list of product backlog items, neatly ordered and estimated. We somewhat managed as a Scrum Team to keep the Sprint Backlog intact during the sprint. But in a context like ours, there’s a lot of dynamics in the Product Backlog. This led to the situation, that the next 1-2 Sprints were somewhat projectable into a release roadmap for me, but after that: pure chaos.
One morning it occurred to me, that not all Product Backlog Items are equal; I quickly sorted them into three buckets, and came up with a metaphor, that works surprisingly well. Considering that this was the first idea I had.
Ladies and Gentlemen, may I present to You: The Product Menu!
The Product Menu – A New Way to Organize The Product Backlog
The Main Dish
This is the main goal. This is what the Development Team will be working on. Every Sprint, we will focus on one main dish. To speak in User Story terms, this is an Epic. Main Dishes can be a hypothesis to test, a nice new feature, an understanding to gather, something to learn about your customers, etc. This is the Sprint Goal, which under all circumstances should be kept. As Product Owner, it is my obligation to break the Main Dish into several User Stories (it’s an epic after all). I think somewhat from 5-10 (one to two hand full) should be ok, so that we have some wiggle room during Sprint Planning. My assumption is, that also within a Main Dish, there’s a diminishing return on investment. So the Scrum Team drives it as far as it makes sense in a single sprint. Every work that is not finished by the end of the Sprint is not delivered; commits can be reverted, braches can be cut off. If I decide that it is wise to pursue the issue further, I will create another Main Dish later.
The Side Orders
With every Main Dish, there will be a few Side Orders in every Sprint. I realize that this is similar to the regular Product Backlog. Side Orders are ordered as I seem fit, but they are also somewhat unrelated. Unrelated to each other (mostly), and also unrelated to a Main Dish. But they need to get done, for whatever reason. So it’s good that with every Main Dish, we add some Side Orders to it. Probably around two to three with every main dish. But this depends on the team and its velocity.
The Snacks
And then, there is this plethora of little things. Minor bugs, little improvements, some technical chores, etc. They should be done eventually, otherwise I’d ignore / delete the tickets right away, but it’s too much hassle for me to bring them all in a decent order. Instead, there’s this pool of Snacks, which the Development Team can pull from as they wish. A Snack should be really small, half a day of work at max, the smaller the better. If I as Product Owner care about when something should be done, I should convert it into a Side Order.
Summary
With the Main Dish, Side Orders and Snacks I hope to find a good balance of focusing on important things, being able to quickly reorganize the Product Backlog, yet keep the effort in doing so minimal. The CenterDevice Scrum Team just started to implement this pattern, so there’s no experience to report on at the moment, but I will keep you posted. From what I heard after initial discussions, it seems to strike a nerve, or at least is considered not completely useless at first glance. Let me know, what You think about the Product Menu. Are going to try this out? Is this a good thing to have in your Product Owner tool belt? How does relate to other practices, that you use (or know)?
Questions & Answers
To keep the description of the Product Menu brief, I’ve factored out some of the discussion to a Q&A section
Is this a deviation from Scrum?
No. According to Scrum, the Product Backlog can change with every Sprint, and it’s the Product Owner’s responsibility to maintain it. Modeling the Product Backlog as Product Menu is just a special way of dealing with the Product Backlog Items.
What about estimation and release forecasts?
While the estimated User Stories help the Team to figure out, how to mix and match a Main Dish with Side Orders during the planning, as product owner, I don’t rely that much on the estimates any more (and probably never did). It’s much easier for me to put a Main Dish into every planned Sprint, and add a few Side Orders to it. This works out good enough for me. Yes, I’ve probably made a step towards the #NoEstimates camp.
In which circumstances should a Product Menu be used?
If I tried to generalize the situation, that CenterDevice is in at the moment – or to be more precise the Core/Web-Team of CenterDevice; others don’t use the Product Menu yet, this is the bullet list:
- There is an existing product. If you started from scratch, I’d probably go only with Main Dishes, and scrap Side Orders and Snacks for the time being.
- The path to the future is not exactly clear, although you do have a great vision. If you don’t need to try things out, but have a clear understanding (well, at least You think you do) of how to proceed, you probably don’t need the Main Dishes, but can live with Side Orders (i.e. the usual Product Backlog) perfectly fine.
- There are a number of customers, who could keep you busy if you let them. If you haven’t released yet, you should 🙂 And if your Backlog doesn’t contain many minor or small items, good for You, well done!
Can a team serve more than one Main Dish?
Sure, why not. For us, this currently wouldn’t work, but why not. Hey, why not scaling your Scrum Team(s) to restaurant scale kitchen chefs?
How to keep the balance between Main Dishes, Side Orders and Snacks?
Experience and collaboration during the Sprint Planning. Keep the balance. If you focus only on the Main Dish, it’s probably boring, so spice it up. If you only Snack, that’s unhealthy too.
Was this post helpful?
More articles
fromAndreas Ebbert-Karroum
18.11.2020 Your job at codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
More articles in this subject area
Discover exciting further topics and let the codecentric world inspire you.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog author
Andreas Ebbert-Karroum
Agile Principal Consultant
Do you still have questions? Just send me a message.
Do you still have questions? Just send me a message.