Webinar #3: Product Backlog Anti-Patterns [Video]

TL;DR: Webinar Product Backlog Anti-Patterns

The third Hands-on Agile webinar product backlog anti-patterns covers common problems from out-dated and oversized tickets to the part-time proxy product owner and his or her idea repository. Learn more about the numerous product backlog anti-patterns that can manifest themselves when you try to create value for your customers and your organization.

Do you want to get this article in your inbox? You can sign up here and join 24k other subscribers.

Update 2018-05-24: The Replay of the Webinar Product Backlog Anti-Patterns Is on Youtube Available

The video of the webinar is now on Youtube available:

Note: If the browser will not start the video automatically, click here to watch the replay of the webinar product backlog anti-patterns directly on Youtube.

Cannot see the subscription form?
Please click here

Update 2018-05-13: The Slide Deck of Webinar Product Backlog Anti-Patterns Is Available

The slide deck of the webinar is available:

If the slide deck will not work within this browser window, please click here to browse the slide deck of the webinar agile product backlog anti-patterns directly on Slideshare. There, you will also be able to download a PDF of the slide deck.

📅 Upcoming Hands-on Agile Webinars

Save the dates:

• On May 22nd, 2018, the fourth webinar will address Agile Failure Patterns in organizations.
• On June 5th, 2018, the fifth webinar will address Sprint planning anti-patterns

📺 Subscribe to Age of Product’s Brand-New Youtube Channel

Now available on the Age of Product Youtube channel:

• Hands-on Agile Webinar #1 on product discovery anti-patterns.

✋ Do Not Miss Out: Join the 3,150-plus Strong ‘Hands-on Agile’ Slack Team

I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.

If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.

Webinar Product Backlog Anti-Patterns — Related Articles

Download the ’Scrum Anti-Patterns Guide’ for Free

---

Transcript Webinar Product Discovery Anti-Patterns

Welcome everybody to the third webinar of Hands-on agile, I’m your host Stefan Wolpers, and today we will be talking about product backlog onto patterns.

A bit background on myself; I’ve been working in the agile industry, making software for 12 plus years now, and mainly with fast-growing venture capital fund and startups in Berlin or with large corporate organizations. At the moment I’m working for a large electricity and gas provider here in Germany. I’m one of the stewards of the XSCALE Alliance, and in my free time I like to run webinars and write blog posts; I guess you know that.

Before we start talking about the product backlog anti-patterns, I would like to make a small detour to make you familiar with my mental model, how agile software development works. So from my perspective, I like to refer to it as the product creation arc. So you start on the left side with a vision that results in a strategy, and you come up with hypotheses, you run experiments to validate or falsify your hypothesis. And based on those results, you start to have a midterm planning, maybe two to six months, so something that looks like a product roadmap. Then you come to the midterm planning for the next four, eight, maybe 12 weeks, in scrum speak people refer to this as the product backlog. And then the next step would be the short-term planning, that would be a sprint backlog for example. Then you start building the product, [and] you deliver the product by shipping code to a resilience system at will. That’s my world.

If you ever look at the left part of the arc, it’s what I like to refer to as product discovery, and the right part of the arc is product delivery, and they meet somehow in the middle. Of course, it’s not a sharp distinction between those both. However, what we can figure out here already is that any kind of product discovery is significantly more low-tech and more affordable, the further to the left side you go. You don’t want to run experiments on the right side because the further you move to the right side, the more expensive the whole thing gets.

This is also the reason why I believe that the product backlog, the midterm planning is so important to make agile product development work for a very simple reason. If we talk about risk mitigation, cost of delay, opportunity cost, misallocation of resources; all these actually can be directly attributed to having the wrong kind of backlog, not getting the product backlog process right.

From my perspective, the midterm planning, the product backlog is crucial to the success of your whole team. It’s the last line of defense to prevent stuff that doesn’t belong there to keep it out of the production process of actually shipping code. From my perspective, it’s the make or break: Is your team supposed to become some internal agency that delivers what other people want them to deliver or will it become the people to go to solve problems your customers have. And I strongly, strongly suggest that you try everything and work becoming a future factory. You need to defend your product backlog with claw and tooth. It’s from my perspective, and in my experience [essential], because otherwise – once something gets in there -, the likelihood that it will be delivered is quite high.

From the product backlog to sprint backlog. First, let’s have a look at how a product backlog/ sprint planning process in practice works. At least this is my version of doing it, and I really like to coach my teams on that, and it has been working fine so far. Imagine the time access and your current sprint, at the same time while you’re working on delivering the codes of what you considered valuable in the last sprint planning, you always start refining all the stuff that you want to work on at least in the next two sprints. So, if you have two-week sprints, we talk about a timeframe of probably about four weeks. Maybe, it’s six weeks or eight weeks depending on how your team works, whether it’s B2C or B2B, whether you ship your product in releases or whether you practice continuous deployment, you have to take the state of your product lifecycle into consideration, so a lot of individually contributing factors here. But in general, it proves to be a good thing.

So what we do religiously is we have our product backlog refinement sessions once a week. We never skip them; we always go through them because it’s the one moment where everyone understands why we’re working on things, how we are probably doing this, and what we are going to deliver. It’s critically important to have everyone from the team on the same page at this moment.

Now, having this general process in mind, I like to switch gears and come to the anti-patterns I’ve been observing for years now, and it’s always been the same. Let’s start with general product backlog anti-patterns. I think the most important one is what I like to refer to as prioritization by proxy. I guess we all know that the product owner is the Achilles heel of the whole scrum framework; it’s this single individual who knows the best use of the team’s time and resources at any given moment. It’s a challenging role, and it’s also the role that is most vulnerable to any form of pressure from the organization. It’s the reason that less for example [inaudible 00:07:06] scrum is also putting so much emphasis on the one product owner that runs the show. It’s really important to preserve this role, to respect this role, and to provide everything the product owner needs to do his or her job.

What’s not working is using the product owner as some proxy for a committee that is designing the product. It always ends in a feature factory. [The proxy PO] has the bitter aftertaste of reintroducing some stage-gate process through the back door. The moment you take away the authority from the product owner role, the moment you start to disrespect the product owner role, you create a quite need waterfall 2.0 process with significantly shorter feedback loops, thus also mitigating the risk of the original process. I think this is the anti-pattern number one: the product owner is not a [real] product owner; you know someone is else is ruling into the product backlog.

Next one, issues turn into artifacts. The first thing I do when I come to a new project is I have a look at the product backlog. Usually, there is a software [like Jira], for example, and I go through all the issues and try to understand what quality the product backlog has at that level. And you always see that the issues are usually not set up in a way that you would expect it from a team that is collaboratively working on something where the issue itself is a token for discussion.

Typically, you will find that a lot of the issues, user stories, for example, are way too detailed. When I was working as a product owner, I was very strict with me in the sense that I defined a catchy headline, that I was able to explain why this story is a good thing, and I came up with two, three, maybe four acceptance criteria. And this is what I took into the product backlog refinement. And then the team was working on this kind of basic information and created something useful out of it in a collaborative effort.

To me, it was always important that the team was in a joint effort creating the stories because this is something entirely different. If you hand over a prepared detailed story, it’s a work of someone else; it’s a kind of task you impose on and the team. However, if the team is collaboratively working on this, it’s their user story, and this is what you want to have. So, too detailed user stories are always a bad sign. Also, if there are no spikes in the whole backlog, how is that supposed to work: do you really know everything in advance? I’m generous with spikes; let’s figure out how something works, and maybe it [will not] work at all, and we skip it. But a backlog without any spikes is causing concern on my side.

Some people run scrum for fixed goal projects, for example, you’re replacing an existing application with a new one on a different tech stack. And always people come up with the idea, “Let’s create all user stories up front.” And I always ask myself, “Okay, why would you do that?” I mean, do you want to have a clone of the old application or while you’re working at it, try to fix the most critical issues that you’ve been running into.

Starting a new project with a product backlog that contains hundreds of stories that are all prepared is really not a good idea. The same applies to a [product] backlog that is already entirely estimated. Once again, estimation is a critical part of the collaborative creative process of user stories, but it’s not about figuring out the future productivity of the teams. It’s again something that is triggering the discussion among the team members; it’s everyone on the same side, do we have an understanding what we’re supposed to build and what the scope is here.

The moment something is completely estimated, it looks to me rather mechanic. Have you really spent all the time on the estimation in a team-based on estimation poker, for example? This is highly unlikely. Very often it’s been the single individual that just puts some numbers in there.

Next one, outdated issues. I think this is self-explanatory. I mean, if we have a planning horizon of four, eight, maybe 12 weeks in total, how can you have issues that are six, nine, or 12 months old? I believe that old tickets are waste, simply waste. They’ve never been valuable enough to be put in a sprint, and if that’s true, why would you keep them? I always suggest to delete everything that older than three months, if it’s important, we’ll come back otherwise it’s decluttering your backlog, so don’t be shy, just kill the stuff.

Oversize product backlog. This is closely related to the other one. I don’t know how people can work with product backlogs [inaudible 00:13:10] of hundreds of issues. I mean, I lose oversight about 60 or 80 or something like that. So [any size over] 100 user stories should raise your suspicion and should trigger some research, what kind of stories these actually are.

If you suggest to the lead of the unnecessary stuff, you’ll typically get two objections: a) we cannot delete them; it’s our documentation for governance reasons, compliance reasons. And b) we put so much work into creating them. [That is the] sunk cost fallacy. Both I believe are not as serious issues that you need to talk about. However, they shouldn’t prevent you from doing what’s right. Keep your documentation outside your ticket system because it doesn’t belong in there. And secondly, it’s not about putting in work upfront; we’re not getting our paycheck for putting work in, we get our paycheck for actually delivering value to customers. It’s a crucial difference from my perspective.

So, an oversize product backlog, not a good idea. Now let’s switch over to our product owner. Probably you have already encountered this special type of product owner. The product owner has absolutely no doubt where go to: I know what we have to build, follow me. He or she also rarely needs the team because collaboration only slows him or her down because – as you know – she or he already knows where to go. So, why have all these discussions about the why, and the scope, and what? It’s really just a bad use of that PO’s time.

Very commonly, he or she also not just provides the why, but also the why and what. You can observe this particularly with former engineers who turned product owner because they always believe, “Okay, I know what to build.” They always have an idea of how to create it themselves, which of course is not a good idea. The combination of a dominant product owner with a submissive team is really about combination because all the checks and balances are gone. The whole idea of having a backlog and the collaborative team approach is to discuss what’s up here and where we should put our money. And this is not just a task of the product owner; it’s also the task of the team to put in their knowledge and their experience and challenge the why. This is one of the noblest tasks the team has: why are we doing things, why should we do things, and why should we build something in the scope that you believe is necessary. So, the [know-it-all] product owner, not a good idea.

There’s a form of product owner that really needs help from the team and probably also training and coaching. It’s not unlikely that former business analysts turn into copy-and-paste product owners because they believe their job is basically to trim a former requirement document of a few hundred pages into smaller pieces by copy- and pasting them into Jira. They have a complete misunderstanding about how this whole thing works, how are we creating user stories, why it is important that it is a collaborative effort and not just one telling the others. It’s really a huge, huge task for the scrum master to get this right. And I strongly suggest that if you’re a coach or the scrum master to reach out to the product owner and ask if you could help him or her. For example, always useful is a basic training of the INVEST model, so independent, negotiable, variable, estimable, small, and testable. So, that’s an issue, and it’s one of the moments where your product owner needs help from the team.

So, the last one on the PO side, the part-time product owner. Am I in favor of minimizing the workload of the product owner? Absolutely. I always try to do so. I’ll try to make the teamwork [together] whenever possible, starting with writing user stories, but not ending there. I am a big fan of actually having the engineers run user interviews and figuring out what the problems of the customers are. It makes communication so much easier, and it’s so helpful in getting the product backlog right. However, I never managed to do this even with a smaller part of the application I was responsible for as a part-time job – it is simply not working. PO is a full-time job. If someone believes it’s a part-time job, you seriously need to talk to responsible people in the organization that there is something completely going wrong.

We were talking about general issues, the product owner, and of course, there are team issues. The most important team issue I have encountered is the product backlog that resembles a random assortment of stuff. Probably, you only have a title of a few words, no one knows what is this all about and why would this be a good idea. That there hasn’t happened any collaboration on the user story itself. There are tickets in there that are completely unrelated to the product. You will find no themes, no epics, you will never find the reason why you would do something, so what are we fighting for? What’s the idea that we are trying to accomplish here? And I believe this is partly due because the team either doesn’t care or doesn’t feel in the right position to speak up and address the issues. Both are critical points that a coach or a scrum master would need to address because this way you can stop doing scrum altogether; Just switch to something else or maybe go back to waterfall [as a process]. It’s the desire of probably being busy but we’re not providing value to our customers and the organization by being busy; it’s outcome-driven, not output. Otherwise, sloppy work is expensive. Don’t turn your backlog into a random assortment of stuff; it’s really not working out this way. Be very, very careful what you let in there, as I mentioned earlier; garbage in, garbage out. And the way we read the fine print if the team is not capable of delivering decent quality and value to the customers.

Okay, the next round. This is overlapping a bit with sprint planning; however, it’s addressing one issue that a lot of teams ignore. It’s about where to allocate time and resources. And I’m a strong advocate that the team’s time should be split. There needs to be slack time for unexpected things, for pairing, for coaching and training other team members and dealing with the unexpected. There always needs to be time – hopefully maybe 20% – to deal with bugs and technical debt. So, we like refactoring. And maybe the remaining 60% can be allocated to new features and new issues et cetera pp.

However, if the team is not capable of getting [this] in the sprint planning, it’s usually because there’s never been part of the product backlog in the first place. I’m a strong advocate of making transparent what the team has to work on, and this implies of course box as well as non-functional requirements or whatever you like to call your tech tasks.

Mike asked what a spike is. A spike is basically a time box when the team decides to allocate maybe two, four, or eight hours on a specific topic to figure out how things are going. For example, the team does not know whether the new version of the JavaScript framework will cause any trouble, so someone may just give it a try and see what’s happening before they start working on this. Spikes are usually very helpful to get a better understanding of an issue: the scope of an issue, what needs to be done, whether additional training is required. It’s a sort of research.

This is an issue. The last issue on the team side is the refinement process itself. This the moment when you do not put enough time into refining user stories. As I mentioned earlier, from my perspective, it’s always a collaborative effort; it’s the whole team working together on getting something right. It’s, of course, helpful to have [it] already because it’s setting a standard, it’s not intended to be a checklist by all means, but it is setting a standard and thus creating a mental model everyone applies unconsciously to creating good user stories or good issues for example.

There is the moment when you do too much of a refinement. You don’t have to break everything down to the last iota in advance; this is too much work. There is another issue that I have observed in a team or two. There is this PO versus team game going on. I do believe that the product owner is part of the scrum team and we’re all wearing the same jersey, and we all work on the same team, and we want to be successful in the end. A bit of haggling is important, it’s a critical part that the team, the engineers, for example, challenge the product owner. However, it needs to come to an end sooner or later because this is getting nowhere if you create some kind of stalemate.

I’ve seen a team using a definition of ready as some kind of stage-gate process, rejecting issues that were okay but because there was missing a small thing for example because the designs were not available the day before the sprint was supposed to kickoff. And the designer said, “Okay, I’m able to deliver this tomorrow.” And they said, “Nope.” Definition of ready, designs have to be available. Otherwise, it’s not eligible to come into the sprint. This is really not the way you should work. This is an issue that the team sometimes has but something that you really can work on.

Good. Before we close, I like to briefly address another issue about product backlog anti-patterns. What we’ve been talking about has been mainly in the realm of the team, dealing with each other, some are more organizational in nature. But I’d like to address the point that dealing with your stakeholders as a product owner can be complicated. And I’m not just referring to the situation that you’re stripped of your authority as this product owner, you’re just product owner by business card, but otherwise other people tell you what to do. This is enough material to have a webinar on its own; I just like to scratch it. Whatever you do, expect flanking maneuvers by stakeholders to get their interests, their issues, their feature request into your product backlog. So, for example, we have one of my favorites: the HiPPO – the highest-paid person’s opinion – drives the product backlog and bypass everyone else. The HiPPO wants something in the product backlog, and the HiPPO will succeed.

Next one, brute force issues, so this is not the product owner but someone in the organization who is very unpleasant to deal with, and typically these bullying methods might work for some time. I think it’s more an issue of startups than of established organizations because startups are more [exposed| influx cultural-wise. This certainly is an issue; if you’re dealing with a startup and you’re prepared that someone is addressing you as a product owner and tries to force things into your backlog, you probably are in the wrong organization.

So, have daddy fix it. Yes, escalation always works. I will tell my boss, and my boss will tell your boss, and then we will see whether my issue is not that important. This is very typical; it’s not just passive-aggressive, it’s also defying the whole idea of Scrum and what a product owner is and how the team works. Bribery, you scratch my back, I scratch your back. And there are countless ways of doing that, and it’s sometimes hard to detect.

Creating tickets directly. This is the fun part. A rookie mistake, if you use Jira, for example, don’t make a mistake and allow other people, particularly stakeholders to create tickets in your backlog; you don’t want to do this. Make sure that everyone from the outside has to go through your process of figuring out whether something is valuable; it’s a competition of ideas. This is unpleasant to a lot of people, particularly if they’re used to giving contracts to outside agencies and those agencies will deliver what they wanted. It’s a completely different model from their perspective. But never allow any stakeholder to create some tickets within your system, not even bug tickets. It’s a very slippery slope, don’t do that because the next variation of that is: why submit to this whole product backlog process as a stakeholder in the first place? Create something and go directly to the engineer and say, “Okay, you’re going to do that.” Very not uncommon with some people from the management level, very nasty, something that needs to be immediately addressed.

The last one is actually quite sympathetic to me because they’re trying to hack the system by sticking to the rules, it’s [sneaking in] feature request as bugs. It’s always funny; you will see there are different variations of those. For example, I was working with one team where we had the idea to have an express lane, so to speak, for small issues. We are all aware if you’re [using Scrum], you’re good at making the big points, the match points but the small stuff that is also nice and valuable sometimes really gets ignored. So we created a small fast lane for the small stuff, and guess what happened, from now on every feature we request was downsized to the level that it would fit into the fast lane.

I liked these issues because it shows that the stakeholders are respecting the process just trying to game it. But this is a good way to start communication and talk them out of that and maybe take them by the hand and show them how this is working in the right way.

Okay, let’s summarize. I believe you need to defend the product backlog at all costs; it’s make-or-break whether your team becomes a real team or will stay with the internal agency and whether you will become the future factory churning out stuff that probably no one is interested. The product backlog is for another reason very crucial because if you do the product backlog refinement in the right way, it’s also a very, very nice way of doing a preliminary sprint planning. My teams spend seriously not more than 15 or 20 minutes on sprint planning one because we talked about this regularly in the days before. When it comes to anti-patterns, there certainly is the missing product owner problem: how do you have a prioritization by proxy, whatever that is, maybe a committee, perhaps another manager, this is not working.

Also, oversizing a product backlog is not a good idea, it’s too much effort, and it’s always tempting to put work into stuff that actually will never be built; that’s a sign of waste. Outdated issues delete them; everything that’s older than three months indeed doesn’t belong in a product backlog. Issues turned into artifacts, also very problematic. Everything that is moving an issue away from this idea of being a topic for discussion among the team members, why they would do this, and how to get it in the right way is a really critical issue, and you should immediately try to fix this. So, not too detailed, certainly not 100% upfront no matter if the scope is fixed or not or of the project or product. Wholly estimated, seriously don’t do that, always stick with the usual timeframe you’re working on, so maybe four, six, eight weeks, no longer than that.

[The] omniscient product owner, we know what we have to do, so the product owner imposing his or her role upon the team. A critical issue [which] needs a lot of training, and probably then you can fix that. You need to speak up, this is certainly an issue of the scrum master or the coach needs to address as soon as possible. Part-time PO simply doesn’t work. What’s also not working is copy-pasting [inaudible 00:34:00] and document into [GIRO 00:34:02] tickets. This is not the idea of user stories and how they’ve been created and why we created them in the first place. A random assortment of stuff. Yub, don’t use your backlog as a repository of ideas and whatever you come across. This quickly leads to an oversize product backlog of low value with a lot of outdated issues, and then you basically can throw it away. Make sure your product backlog reflects all the work that is necessary; I always advocate for putting non-functional requirements, technical tasks, or box into the product backlog so everyone can see when you do the product backlog refinement what is up and what needs to be addressed.

And lastly, collaboration as a team on creating issues, user story refinement is a very good idea, however, don’t overdo it. You need to find your balance, how to do this, and please try to avoid using your definition of ready as a kind of stage-gate to structure the communication between the engineers and the product owner. This kind of collaborating is not a good idea so that needs to be overcome. Also, because otherwise, the team will not be successful.

That’s it from my side. The next webinar will be in two weeks time, and we talk about agile failure patterns, typical observations why agile is not working in the organization, which I believe is sending a certain message to every one of us; you never walk alone, all your trouble is shared by a lot of other people around the world.

Okay, if you want to contact me, I think you will know by now where to find me.

[The Q&A section was not transcribed.]

So, thank you very much, and I hope I will be able to provide the video in about one or two week’s time. Okay, thank you, everybody. Have a nice day.

📅 Scrum Training Classes, Workshops, and Events

You can secure your seat for Scrum training classes, workshops, and meetups directly by following the corresponding link in the table below:

See all upcoming classes here.

You can book your seat for the training directly by following the corresponding links to the ticket shop. If the procurement process of your organization requires a different purchasing process, please contact Berlin Product People GmbH directly.