The No-Scroll Bar Rule—Empowering PO’s Through Constraints | Joel Bancroft-Connors

Summary

Scrum Master Toolbox Podcast: Agile Storytelling from the Trenches Episode: The No-Scroll Bar Rule—Empowering PO’s Through Constraints | Joel Bancroft-Connors
Host: Vasco Duarte
Guest: Joel Bancroft Connors
Release Date: June 6, 2025

---

Introduction

In this insightful episode of the Scrum Master Toolbox Podcast, host Vasco Duarte welcomes Joel Bancroft Connors, an experienced Agile Coach and Scrum Master, to discuss common anti-patterns in Product Ownership and effective strategies to empower Product Owners (POs) through intentional constraints. The conversation delves deep into optimizing team dynamics, enhancing communication, and fostering an environment where developers can thrive creatively within Agile frameworks.

Product Owner Anti-Patterns: The BA That Can't Let Go

Joel begins by addressing a prevalent anti-pattern he has observed in Agile teams: having both a Product Owner and a Business Analyst (BA) on the same team. He explains how this setup often leads to a "game of telephone," resulting in miscommunication and inefficiency.

“Anytime you have multiple lines of communication, things are going to fail.”
— Joel Bancroft Connors [02:04]

Joel shares his experience where a BA struggled to relinquish control, over-documenting requirements and hindering the development process. This micromanagement stifles developers' autonomy and creativity, leading to less effective outcomes.

The No-Scroll Bar Rule: Enforcing Concise Documentation

To combat the issue of over-documentation, Joel introduces his innovative "No Scroll Bar Rule." This rule mandates that the description field in Jira (or similar tools) should fit within 10 lines and 120 characters per line, ensuring clarity and brevity before engaging with developers.

“My rule is called the no scroll bar rule. The description field in Jira... there should be no scroll bar on the description field.”
— Joel Bancroft Connors [04:52]

This constraint forces POs to distill requirements to their essence, promoting clearer communication and enabling more effective discussions with the development team.

Empowering Developers Through Constraints

Vasco and Joel discuss the importance of empowering developers by limiting the extent of detailed instructions, allowing them to inject technical innovation and ownership into their work.

“We want to unleash them. We want to give them problems... create awesome and we'll give you feedback along the way.”
— Vasco Duarte [06:12]

Joel reinforces this by emphasizing that product owners should provide a clear vision without dictating every implementation detail, fostering an environment where developers can contribute their unique insights and expertise.

Effective Product Owner Collaboration: A Dual PO Approach

Joel shares a compelling case study from his experience with an insurance organization that successfully employed a dual Product Owner model. By pairing a business-oriented PO with a design-focused PO, the teams were able to leverage complementary skills, leading to a significantly reduced project timeline from 18 months to just six months.

“They’re going to work together because it’s a shared product goal... build it in, I think it was about six months.”
— Joel Bancroft Connors [12:12]

This collaboration ensured that strategic business goals and user experience designs were seamlessly integrated, demonstrating the power of diverse skill sets working towards a common objective.

Complementary Skills: Enhancing Team Collaboration

The conversation highlights how collaboration thrives when team members bring complementary skills to the table. Joel illustrates how blending business acumen with user experience expertise can create a more robust and effective product development process.

“The business person and the designer both got better... reflecting back to start with why.”
— Joel Bancroft Connors [13:21]

By focusing on a shared persona and aligning team efforts with the overarching "why" of the project, teams can maintain a united direction while benefiting from diverse perspectives.

Embracing Agile Principles: Start with Why

Joel and Vasco conclude by underscoring the fundamental Agile principle of "Start with Why," advocating for teams to understand the purpose behind their work to ensure meaningful and high-value outcomes.

“Build projects around motivated individuals, give them the environment and support they need to get the job done... tell them what you want and then get the heck out of their way.”
— Joel Bancroft Connors [07:49]

This principle not only fosters motivation but also enhances the overall effectiveness and satisfaction of the team, aligning perfectly with Agile methodologies.

Conclusion

This episode provides valuable insights into optimizing Product Ownership within Agile teams. Joel Bancroft Connors offers practical strategies, such as the "No Scroll Bar Rule" and dual Product Owner models, to mitigate common anti-patterns and empower teams effectively. By fostering clear communication, leveraging complementary skills, and adhering to core Agile principles, Scrum Masters and Agile Coaches can significantly enhance their team's performance and product outcomes.

For more resources and to connect with Joel Bancroft Connors, visit thegorillacoach.com or follow him on LinkedIn.

---

Resources Mentioned:

• Scrum Master Toolbox Membership
• Joel Bancroft Connors' Website: thegorillacoach.com
• Agile Coaching and Training at scrumaliance.org

Subscribe and Rate: If you found this episode valuable, please rate it on your preferred podcast platform and share it with fellow Scrum Masters and Agile practitioners.

Transcript

[Vasko]

Hey there, agile adventurer, just a quick question. What if, for the price of a fancy coffee or half a pizza, you could unlock over 700 hours of the best agile content on the planet? That's audio, video, E courses, books, presentations, all that you can think of. But you can also join live calls with world class practitioners and hang out in a flame war free and AI slop clean slack with the sharpest minds in the game. Oh, and yes, you get direct access to me, Vasko, your Scrum Master Toolbox podcast. No, this is not a drill. It's this Scrum Master Toolbox membership. And it's your unfair advantage in the agile world. So if you want to know more, go check out scrummastertoolbox.org membership, that's scrummastertoolbox.org Membership. And check out all the goodies we have for you. Do it now. But if you're not doing it now, let's listen to the podcast.

[Unknown Host]

Hello everybody. Welcome to our Friday the Proctor episode. Also TGIF episode this week with Joel Bancroft Connors. Hey Joel, welcome back.

[Joel Bancroft Connors]

Thank you. Friday, where has the time gone?

[Unknown Host]

Yeah, it's almost like an hour ago. It was Monday, huh?

[Joel Bancroft Connors]

Absolutely. Yeah. I just feel like I just stepped out of the tardis.

[Unknown Host]

There you go. Beautiful Doctor who reference there. So we talk about great product owners at the end because we always want to end up on a high.

[Vasko]

Of course.

[Unknown Host]

But Joel, product owners aren't always their own best supporters or helpers of the business. Sometimes there are some difficult patterns that they tend to take on. So let's explore one of those. First, what was potentially the worst product owner anti pattern you've witnessed in your career?

[Joel Bancroft Connors]

Well, I almost picked myself because before I was a project manager, back in the previous century, the 1990s, I was actually a product manager. And there's a lot I didn't understand then, which I now I wish I could go back and write a letter to myself. Back then I probably would still be in product management and very happy doing it. But the worst product owner anti pattern I've seen in my time in Agilent Scrum is, I call it the BA that can't let go. So the first thing we have to talk about is kind of an anti pattern and that is that having a business analyst on a Scrum team. I think business analysts are awesome. I think they're great if we give them the right support. What I think is an anti pattern is having a product owner and a business analyst on the same team because you're just creating a game of telephone because the product owner is saying something and then the business analyst translates it and then the developers go to build it. And that's. Anytime you have multiple lines of communication, things are going to fail. I think then what we have to do is business analysts like Bob Galen talks about in his book Scrum Product Ownership. Business analysts can be perfectly good product owners as long as we give them that why? And we give them the support to be a good product owner. The challenge is some business analysts can't let go of the. I have to do everything. I have to document all to the. To the nth degree. I have to document every single use case and all of this stuff. And it's like it takes me three weeks to get a product backlog item ready. And then. But when I'm done, I can hand it to the ba, I can hand it to the devs and they can do that. And I worked with a BA at a credit union that was like this and it's like, we want, let's make her the product owner. Okay, that's great. And I'm coaching her through all of this and she just, she couldn't let go. But I can't let the developers do that. The developers don't know that or whatever. It's like, aren't they really smart people? Well, yeah, but I got to tell them exactly what to do. But if you tell them exactly what to do, they're only going to do exactly what you tell them to do. And that's not what we want. We want to unleash them. And I think that's the first time I ever used my analogy of imagine hiring Michelangelo to paint the Sistine Chapel and giving him a paint by numbers kit. And that's exactly what she was doing, was she was telling them exactly what to do all the way down to the last little detail. I actually have a one minute YouTube video that was also inspired by this and it's the how much should a product owner document before going and talking to the developers? And since we all using electronic tools these days, Jira, Azure, DevOps or whatever, my rule is called the no scroll bar rule. The description field in Jira, we'll just pick on Jira for right now. The description field in Jira, it's about 80 to 120 characters wide and about 10 lines deep. My rule is no scroll bar before you talk to the developers. When you look at the description field, there should be no scroll bar on the description field. So it's all got to fit into that 10 lines of data that's enough to be able to go have a conversation with the developers. That was what I had to work with this BA on eventually. Unfortunately they just didn't get it and we had to move that BA off to a non agile project where they could be happy doing BA work and we brought in somebody who didn't have the deep level of knowledge that this BA had. However, what they did have was they understood the customer and they focused on the customer and let the team focus on how to get the work done.

[Unknown Host]

Yeah, and when you say unleash the developers, I think there's, at least from my perspective it's important to kind of highlight that the idea here is not to abandon the developers, but rather to allow them to bring in the technical innovation perspective that only they can bring in. The BA or PO can never do that because they're not actually typing or testing the code. They can't come up with ideas that you would need to understand the code to come up with. Right. And I think that the beauty of Scrum is that you have these two sides that are working together. And the problem with traditional waterfall like approaches is that there's this clear separation of concerns where one sends over the wall the fully specced out functionality, not allowing there for the developers to take ownership of the work that they're doing and also to contribute their technical vision and innovation to what has been decided to be done. Right.

[Joel Bancroft Connors]

Yeah. And it's the, it's. I think a product owner needs to recognize even though they're technically an equal to the developers and the Scrum master, the product owner has certain positional authority because they own value. And so if the product owner says do it this way, quite often we've spent decade decades teaching people in doing roles to do what they're do, do what the, what they're told. You say here, build it this way with the button over here and the developer is going to go, okay, great, I'll do it that way. What we want though is we want them to instead give them problems. Give them. Here is a canvas, here's what I'd like it to look like. Go create awesome and we'll give you feedback along the way.

[Unknown Host]

Yeah, exactly. Go create awesome and we'll give you feedback along the way. That's a great way to put it. And also what the core of agile is, it's right there in the values principles. Do something quickly, show it to someone running, get feedback and then do the next iteration of it.

[Joel Bancroft Connors]

Well, and that's why Principle 5 of the manifesto is my favorite principle. Build projects around motivated individuals, give them the environment and support they need to get the job done, I. E. Tell them what you want and then get the heck out of their way.

[Unknown Host]

You know what, ironically, that's one of those principles that you could have asked from a project manager anywhere, even waterfall project matters, and they would probably agree with it, at least the good ones.

[Joel Bancroft Connors]

Yeah, I think the principles of Agile are universal and in fact we're seeing this with Project Management in International with its strategic partnership with the Agile alliance and they're continuing work. In the 1990s they were big design up front and then as the 2000s came along they moved to rolling wave planning. But now they're recognizing that the power of Agile is continuous planning. And even PMI is promoting this concept and living into those Agile principles. You don't have to use Scrum to be agile. You can build a nuclear reactor using Agile principles. Because who can argue with motivated individuals? Who can argue with reflecting regularly on effectiveness, who can argue with the people doing the work are probably the best ones to say whether or not it's actually going to work?

[Unknown Host]

Yeah, absolutely. Okay. But there aren't only bad product owners, some product owners out there are amazing and we owe them some debt of gratitude and therefore we want to highlight some of them. So Joel, share with us the best product owner that you've ever worked with. How did they work?

[Joel Bancroft Connors]

So. Sure thing. So bear with me because it's going to sound like an anti pattern at first because you see there's these two product owners, only they weren't working on the same team. I was working with an organization they were doing, it was another insurance organization and they had been building, trying to build this new electronic flow. They'd been literally, you wanted to buy insurance, you had to go to an agent and they still worked on a green screen terminal in an agent's office. And the API people had said we have to do all of this stuff for months and months before anybody else can do anything. Well, leadership was frustrated, let's say and they want, they wanted something different. And I was brought in to coach and be the Scrum master for those two teams actually work with another, the on site Scrum master. And so we paired up together and we had a product owner from the business, but he didn't really understand Scrum and he didn't understand anything about product development. He knew insurance really well. And then we also. This was going to be a highly user experience, a lot of UX in it and we had this really brilliant designer who'd been working off to the side and had really great ideas and also was a really great personality. And we were going to have two scrum teams and it's like, well, what do we do? We're going to need two product owner product owners. And they said, well, we're going to have this person be a product owner. And it's like, I looked at this person, I interviewed them and I went back and I talked with the director. I said, he has no business being a product owner. He doesn't understand the why. He does, he doesn't understand anything about the product stuff. He's a project manager who has never learned the art of product management. And they said, well, who should be the product owner? I said, the designer. The designer doesn't know anything about the business. True. But the business guy does and the business guy doesn't know anything about how to build these products or whatever. Together though, they've got everything we need. We have two teams. We're going to make them product owners of each team. They're going to work together because it's a shared product goal. They had the same product backlog, the same product goal with two teams working on it. And so each product owner had their own team. The business person also focused at the strategic level of the overall product goal. And then the designer was focused on design across the two teams. And while it wasn't the, the perfect thing, them working together really caused these two teams to be able to work independently and yet very closely side by side towards that same product goal. And they were able to do amazing things and take something that some people had thought was going to take 18 months and build it in, I think it was about six months. Wow.

[Unknown Host]

And this actually brings to my mind this idea. I mean, in Agile we always talk about collaboration, right? Like collaboration is important. You need to get people in the same room or virtual room in order for them to talk to each other, understand what needs to be done together and so on. But one thing that we very often don't talk about is this idea of complementary skills. Collaboration can emerge in a group of people that have the same skills. But it really shines when you need to have complementary skills because that's where collaboration really, you know, it's, it's a question of the sum of the parts or. Yeah, the sum of the parts being much better than the two parts. Right. Like it's, it creates something new. And those two perspectives, the designer with the user centric perspective with the usability and interaction and Experience, perspective, the business person, we understanding of the business. These two working together can create something that neither of them apart could, nor two business people, nor two designers could.

[Vasko]

Right.

[Unknown Host]

And I think that this is a beautiful example of that idea that collaboration really shines when you have people with different skills that are collaborating on something where all the skills are needed.

[Joel Bancroft Connors]

Yeah, the business person and the designer both got better. The business person understood more about user experience and everything. That business person, they knew insurance products, they didn't know anything about even what the mainframe that people were using in the insurance offices. The designer, though the designer knew computer products and new user experience and what users were expecting, he didn't know anything about insurance. And in fact, when we did a team liftoff for these teams using the book Liftoff by Ainsley Nees and Diana Larson, that was one of the first things we did was we spent a half a day with the director of the organization, organization coming in and literally what is an insurance product? What is it we're selling? Why is this important? What do we have today? And from that we created a Persona with the team that was in part informed by the business, in part informed by the UX guy who knew how to do create Personas. And we literally had the Persona up on the wall and the developers started referring to the Persona by name in these refinement sessions because we created, we connected it all back to start with why. And so it goes all the way back to my book on Tuesday of Start with why. Simon Sinek.

[Unknown Host]

Yeah, absolutely. And this beautifully wraps up the week in this what I said, you what I told you in the preparation, like you really wrapped up the message so beautifully in this week. There's so many angles on the same message that you brought. Start with why, understand why we're doing the things we're doing so that we can show the value. That's a beautiful way to wrap it up, Joel. Thank you very much. But before we go do share with us, where can people find out more about you and the work that you're doing?

[Joel Bancroft Connors]

Absolutely. So I do have a website, thegorillacoach.com I post article, longer form articles and facilitation guides such as a team estimation facilitation guide. I post every single day. I have posted since the beginning of the year. I posted every single day without fail on LinkedIn on practical stuff. Right now I'm doing a series on Mondays, a Sprint in the Life of the Scrum Master. I just finished a whole 15 part series on a Sprint in the Life of a product owner. Fridays are my facilitation Fridays I always post a facilitation technique and Sundays are always my funny where I take a look at some absurd way that we are doing Scrum or Agile and try and make light of it. So follow me on LinkedIn. And of course I also do teach certified Scrum classes, csm, cspo, all of the advanced certifications and you can find me scrumaliance.org if you look under training and you filter by Joel Bancroft Connors, you can see all my training classes and reach out to me for a discount code.

[Unknown Host]

Absolutely. And we'll put that note in the show notes everybody. The links will be in the show notes for you to easily find them, of course. And why not reach out to Joel, start up a conversation and asking about some of those funnies. Sunday funnies sounds like a great way to start the conversation. Joel, thank you very much for your generosity with your time and your knowledge.

[Joel Bancroft Connors]

Thank you Vasco. It's been an honor and a privilege to be on such a well regarded podcast.

[Vasko]

All right, I hope you liked this episode. But before you hit next episode, here's the deal. This podcast is powered by people like you, the members who wanted more than just inspiration. They wanted real tools and real connection to people who are practicing Agile. Every day we're talking access to over 700 hours of agile Gold, CTO level strategy talks, Summit keynotes, live workshops, E courses, Deep Dive interviews, books. And if you're into no estimates, we got the pioneers of no estimates in those Deep Dive interviews as well. Agile Business Intelligence, creating product visions, coaching your product owner courses. You name it. You'll get invites to monthly live Q&As with agile pioneers and practitioners, plus a private Slack community which is free of all of that AI slop you see everywhere. And of course without the flame wars. It's a community of practitioners that want to learn and thrive together. It's the best place to connect with community and learn together. So if this podcast has helped you before, imagine what you will get from this podcast membership. So head on over to scrummastertoolbox.org membership and join the community that's shaping the future of Agile. We have so much for you, so check out all the [e-mail] membership because listening is great. It's important. But doing it together, that's next level. I'll see you in the community. Slack.

[Unknown Host]

We really hope you liked our show. And if you did, why not rate this podcast on Stitcher or itunes share this podcast and let other Scrum Masters know about this valuable resource for their work. Remember that sharing is caring.