If you have both business and technical people on the same Scrum team, let me start with this: That’s awesome!
Too many teams are still organized around silos. Business over here. Tech over there. Maybe design somewhere in the middle trying to translate.
And when people can’t talk to each other just because they have different skill sets, you don’t really have a team: you have specialists in a vacuum.
What a waste.
The whole point of a team is that people with different skills work together towards a shared goal. We see this everywhere else. In football, we don’t split the quarterbacks, receivers, and offensive line into separate teams just because they have different responsibilities. They play together. Different roles, same objective. They may come on the field at different times, but they're still on the same team.
Scrum is no different.
So, if you’re lucky enough to have business and technical people on the same Scrum team, here are a few things to keep in mind:
1) Don't get carried away with "how" during refinement.
In refinement, the goal is to make sure everyone understands what’s being built and why. The goal of refinement is to add detail, order and size to items in the Product Backlog. Don't get too hung up on the detailed plan for how everything will be delivered. You can start to talk about how everything will be delivered during Sprint Planning, and your full plan for the "how" will be further developed during the Sprint itself.
There's several reasons for this.
First, it's a waste of time to spec out how you will deliver everything because plans change. A lot. So don't spend a bunch of time figuring out how to code every last thing on the Product Backlog.
And second, we need just enough information to size it, not a full breakdown of how the work will be done. Because the way you deliver something will change depending on what all gets pulled into the Sprint. Here's why: Think of a house redesign. If your backlog includes “install quartz countertops” and “install tile in the bathroom,” you don’t need to decide who’s going to the store during refinement. If both items land in the same Sprint, you might combine the trip. If not, you plan differently.
Same in software. If two updates hit the same page in one Sprint, you’ll approach it differently than if they’re done separately.
Refinement is about understanding what's coming next and removing dependencies, but not fully fleshing out how everything gets done.
2) Don’t confuse collaboration with over-explaining.
When different skill sets are involved, there’s a temptation to explain everything. That usually just wastes time.
Not everyone needs every detail. Keep the conversation at a level where people can contribute, not tune out.
3) Align on the problem before debating the solution.
Different roles jump to different solutions. Developers think systems. Designers think experience. Business thinks outcomes. And that's all fine. We want different perspectives.
But if you don’t align on the problem first, you’ll get good ideas pulling in different directions. Start with: What are we trying to accomplish?
4) The Product Owner creates focus with a clear Product Goal
A clear Product Goal creates a direction of travel for the Product, which is important when you have different perspectives working together. Without a clear Product Goal, the Scrum team is like a ship without a rudder. They may be going somewhere, but is it the right somewhere? Multiple perspectives are great, but we need to be focusing in the same direction. Moreover, with the new tools coming into play from AI, it can be easy to lose sight of what we are trying to accomplish - especially when there are such shiny new approaches out there. It's all tempting, and distracting. The Product Goal creates focus and direction for the Scrum team.
5) Are your business people doing user acceptance testing?
Sometimes business folks on a Scrum team are responsible for user acceptance testing. That is wonderful. Be sure and cut your work small enough so that there is time to design, develop, test and do user acceptance testing - all in the same Sprint. You don't want your user acceptance testing to drag into the next Sprint. Try limiting work in progress to make sure that you are able to consistently get to 'done' by the end of the Sprint. Also, try creating a Definition of Done so that everyone understands the scope of what is expected for each Product Backlog item when it gets pulled into a Sprint. That shared understanding alone can be half the battle.
Final Thoughts
You might notice that all of this is just good Scrum. That's because Scrum was intended for teams with diverse skill sets. This isn’t a special case; this is the point.
And it’s only becoming more true. With AI lowering barriers, designers are coding more, developers are thinking more strategically, and Product Owners are getting closer to design. The lines are blurring.